言歸正傳，這篇文章的目的是將新版的捷徑檔快速匯入至舊版的 Workflow 裡。由於 iPad mini 1 只能升級到 iOS 9，所以捷徑在 iOS 12 正式登場之後，Workflow 的同步功能立刻就消失了。問題是捷徑主要是增加 Siri 的支援 (事實上 Siri 的支援我從來不用的)，以及少數的新功能，大部分的功能在舊版 Workflow 上還是可以用的，直接判 Workflow 死刑也太說不過去。所以在同步功能死掉之後，我的想法是將捷徑備份檔中可以用的捷徑匯入至舊版 Workflow 中，所以我讓 iPad mini 1 從我的網誌舊文下載安裝 Shortcut Backup，然後使用匯入功能 ....
於是我看到上圖的訊息 .... 唔，似乎原因是 Workflow 無法打開 shortcut 檔，好像也挺合理 .... 等等，那我在網上從捷徑分享網址下載的捷徑是怎麼匯入的？因此，我猜測 wflow 檔及 shortcut 檔根本是一樣的東西，只是改了副檔名而已，而這就是我寫 File Renamer 的起因，是的，就是這麼單純，難以置信 iOS 至今依然沒有官方支援的批次修改檔名的方法，或許這是 iOS 的中心思想之一，也就是讓檔案管理軟體 (像 Finder) 消失，一切用資料庫軟體管理 (像 iTunes 及 Photos)，檔名則不再重要。
在我完成 File Renamer，也將其改成固定修改副檔名的模組，並插入 Shortcut Backup 之後，發現的確能匯入了，但每次匯入一個 workflow 就會打開一次，第二個及後續 workflow 的匯入都會失敗。這是由於舊版的 iOS 系統還不支援檔案多開，所以不能讓一個 App 連續打開多個文件，雖然這樣多開貌似沒有什麼意義，但是最簡單的多檔案匯入就是靠多次執行 "Open In.." 來達成。之所以需要系統的支援，是因為 Workflow 從一開始就不支援背景執行，一旦跳到別的 App，甚至是 Workflow App 內的另一個 workflow，原本正在執行的 workflow 都會立即停止，即使加入 "Wait for Run" 也沒有用，而 "Run Workflow" 無此問題，這就是系統有特別支援的例子。捷徑也有類似的問題，但對於執行到一半的部分會保留住，切回原捷徑檔則會繼續執行 (有些例子可以、有些不行，原因未知)，可是依然不能背景執行，這就大大地限制了捷徑的泛用度。
事實上，Workflow 之所以被稱作 Automator for iOS，不只是模組化的操作很像 macOS 的 Automator，在程式語言的傳承上也很類似 Automator。在 macOS 上，系統內建的自動化程式語言是 Applescript，而 Automator 則是將各程式支援 Applescript 的功能做成方便一般人使用的模組；在 iOS 上，自動化的程式碼為 URL Scheme，這種程式碼是以類似網址的形式去指定某個 App 執行它的某個功能，比如說 Firefox for iOS 的開啟網址的功能：
即為以 Firefox.app 打開網址 "https://www.google.com"。這樣的功能在 iOS 上存在已久，在 iOS 6 上流行很久的 "用網址撥打電話" 等等功能就是 URL Scheme 的基本應用。在 Workflow 問世之前，URL Scheme 是許多 iOS geek 用來自動化 App 工作流程的主流方法，但它也有一些缺點：
我不打算展開講 x-callback-url 如何使用，簡單地說它必須一開始就放在 URL 裡面，告訴 App 執行完一個功能就要跳回來執行下一個功能，而所謂的 "下一個功能" 可以是同個 App 的其他功能，或是打開另一個 App 並用它來辦事，所以它並沒有解決背景執行的問題，而是把複雜的流程從一開始就規定好而已。由於 x-callback-url 在使用上必須層層疊套，就像數學上的括弧，式子一複雜就括弧一大堆，搞不清楚誰是誰，所以利用 x-callback-url 寫的 URL 最好也不要超過三個動作，不然會非常亂。以我的需求，我可能一次要匯入一大堆捷徑，除非利用 Draft 等 App 的 "變形" URL 的幫助，不然非常難處理，而我也不知道 x-callback-url 最多能加幾個步驟 ....
更糟糕的是，由於 x-callback-url 必須跟 URL Scheme 配合，而當我查閱 Workflow 的開發文件時，我發現 "開啟" (open，非執行 run) 的功能只能開啟本機的 workflow，還沒存入 (待匯入) 的不行；"匯入" (import) 功能必須要輸入該 workflow 檔的 URL，一般來說也就是我們分享到網路上的 workflow 或捷徑的網址。
由於 "匯入" 支援 silent 參數，所以在匯入時可以不開啟該 workflow，也就是說不需使用 x-callback-url 了，但 URL 還是需要解決，總不可能傻傻地上傳吧？這時我想起一位網友分享的 Data URI 方法，它可以把檔案轉換成符合 URL 規範的格式：
[data] 為待匯入 workflow 經過 Base64 編碼之後的字符。如果懶得動手，可以下載我改的 Workflow Backup，裡面除了匯入備份的功能有修改之外，其餘的功能均不受影響，而舊版 Workflow 已經不能用內建的分享功能，所以我將檔案放在 Dropbox 上，開啟之後用 Export > Open In.. 功能選擇 Workflow 即可。
說到這個 Data URI，最一開始我看到該篇文章的時候距離他發文已經非常久了，而當時 iOS 也已經支援多開檔案，於是我想說這種舊方法應該這輩子不會用到了。沒想到，後來寫了 Shortcut Backup，回到舊版 Workflow 發現問題，搞來搞去發現還是必須用這個不是很直覺的方法，這就是人生啊 .....！另外，在 Data URI 裡用 Base64 編碼的捷徑檔案可以直接匯入舊版 Workflow，所以 File Renamer 也不需要了，這 .... 就是人生啊 ....orz
附註
1. 說到這點就不能不吐槽 Wechat，作為一個用戶數量破億的 App，連推播訊息跳轉到發訊者都做不到，實在丟臉。
2. 如果有人不知道的話 ... 開啟這個資料庫的方法是：打開 Script Editor，找到 File > Open Dictionary... 的選單，就可以將系統裡 "所有" 支援 Applescript 的軟體列出，並查看它們支援的 Applescript 指令 (雖然我覺得不是很容易使用，因為沒有包含實際的範例)。
3. 之所以搞成這樣，或許是 Apple 覺得折騰 URL Scheme 這種 "dirty work" 就由開發者來做就好，包成捷徑模組之後沒人知道底層是什麼指令，所以不管開發者自己怎麼亂搞。但是多數第三方開發者都在敷衍 Apple，除了一些大公司 (像 Evernote) 及收費的 App，沒幾個第三方 App 的捷徑是有用的，其內部功能更是幾乎都不支援捷徑。
firefox://open-url?url=https://www.google.com
即為以 Firefox.app 打開網址 "https://www.google.com"。這樣的功能在 iOS 上存在已久，在 iOS 6 上流行很久的 "用網址撥打電話" 等等功能就是 URL Scheme 的基本應用。在 Workflow 問世之前，URL Scheme 是許多 iOS geek 用來自動化 App 工作流程的主流方法，但它也有一些缺點：
- 必須由 App 開發者主動支援：這也造成絕大多數 App 都不支援 URL Scheme，頂多讓你開啟它，內部的功能都不支援 [1]，而支援度高的 App 幾乎都是收費的生產力 App，比如說 Draft、Launch Center Pro。
- 語法不規範：URL Scheme 的語法完全沒有規範，去猜測某功能的語法是沒有意義的，有些 App 甚至連開頭的 scheme 都改掉了，像 Coursera App 的是 "coursera-mobile:"，這沒查開發文件哪會知道？
- 開發文件取得不易：Apple 對於 iOS App 的上架與否有很強的控制力，甚至 iOS 12 開始強制要求第三方開發者讓他們的 App 支援捷徑 (雖然我覺得大部分開發者只是應付了事，像 Facebook 這種大公司更是甩都不甩)，但詭異的是 Apple 似乎一點都不想在捷徑的源頭，也就是 URL Scheme 上做出語法的規範，連開發文檔都不像 Applescript 有一個統一儲存的地方 [2]，當用戶自己上網找的時候，就能體會各家文檔水平參差不齊的不爽 [3]。
- 單方向執行：由於 Workflow 及捷徑均不支援背景執行，所以一旦跳到別的 App 之後就結束了，沒辦法再進行下一個步驟，要解決這個問題，就必須用更複雜的 x-callback-url 功能，可是這玩意也需要開發者主動支援，而支援這貨的 App 更少。
我不打算展開講 x-callback-url 如何使用，簡單地說它必須一開始就放在 URL 裡面，告訴 App 執行完一個功能就要跳回來執行下一個功能，而所謂的 "下一個功能" 可以是同個 App 的其他功能，或是打開另一個 App 並用它來辦事，所以它並沒有解決背景執行的問題，而是把複雜的流程從一開始就規定好而已。由於 x-callback-url 在使用上必須層層疊套，就像數學上的括弧，式子一複雜就括弧一大堆，搞不清楚誰是誰，所以利用 x-callback-url 寫的 URL 最好也不要超過三個動作，不然會非常亂。以我的需求，我可能一次要匯入一大堆捷徑，除非利用 Draft 等 App 的 "變形" URL 的幫助，不然非常難處理，而我也不知道 x-callback-url 最多能加幾個步驟 ....
更糟糕的是，由於 x-callback-url 必須跟 URL Scheme 配合，而當我查閱 Workflow 的開發文件時，我發現 "開啟" (open，非執行 run) 的功能只能開啟本機的 workflow，還沒存入 (待匯入) 的不行；"匯入" (import) 功能必須要輸入該 workflow 檔的 URL，一般來說也就是我們分享到網路上的 workflow 或捷徑的網址。
workflow://import-workflow?url=[url]&name=[name]&silent=true
由於 "匯入" 支援 silent 參數，所以在匯入時可以不開啟該 workflow，也就是說不需使用 x-callback-url 了，但 URL 還是需要解決，總不可能傻傻地上傳吧？這時我想起一位網友分享的 Data URI 方法，它可以把檔案轉換成符合 URL 規範的格式：
data:text/workflow;base64,[data]
[data] 為待匯入 workflow 經過 Base64 編碼之後的字符。如果懶得動手，可以下載我改的 Workflow Backup，裡面除了匯入備份的功能有修改之外，其餘的功能均不受影響，而舊版 Workflow 已經不能用內建的分享功能，所以我將檔案放在 Dropbox 上，開啟之後用 Export > Open In.. 功能選擇 Workflow 即可。
說到這個 Data URI，最一開始我看到該篇文章的時候距離他發文已經非常久了，而當時 iOS 也已經支援多開檔案，於是我想說這種舊方法應該這輩子不會用到了。沒想到，後來寫了 Shortcut Backup，回到舊版 Workflow 發現問題，搞來搞去發現還是必須用這個不是很直覺的方法，這就是人生啊 .....！另外，在 Data URI 裡用 Base64 編碼的捷徑檔案可以直接匯入舊版 Workflow，所以 File Renamer 也不需要了，這 .... 就是人生啊 ....orz
附註
1. 說到這點就不能不吐槽 Wechat，作為一個用戶數量破億的 App，連推播訊息跳轉到發訊者都做不到，實在丟臉。
2. 如果有人不知道的話 ... 開啟這個資料庫的方法是：打開 Script Editor，找到 File > Open Dictionary... 的選單，就可以將系統裡 "所有" 支援 Applescript 的軟體列出，並查看它們支援的 Applescript 指令 (雖然我覺得不是很容易使用，因為沒有包含實際的範例)。
3. 之所以搞成這樣，或許是 Apple 覺得折騰 URL Scheme 這種 "dirty work" 就由開發者來做就好，包成捷徑模組之後沒人知道底層是什麼指令，所以不管開發者自己怎麼亂搞。但是多數第三方開發者都在敷衍 Apple，除了一些大公司 (像 Evernote) 及收費的 App，沒幾個第三方 App 的捷徑是有用的，其內部功能更是幾乎都不支援捷徑。
沒有留言:
張貼留言