さて4回目のWorkflow講座。
Workflowの考え方はシンプルです。
入力された内容を上から下に向かって順次処理していく。
しかし外部のアプリを介した結果をフローに組み込みたいとなるとちょっと工夫が必要になってきます。
今回解説するのがフローを組み立てる上で非常に大切なポイントとなります。
外部アプリからのコールバック
他のアプリを介しても処理を継続させるためにはコールバックを使わなくてはなりません。
DraftsやChromeなどの公式にサポートされているものであれば、自動的にコールバックが付与されるので気にする必要はありませんが、そうしたアプリはごく少数。
それ以外のアプリで使うためには自分でURLスキームを書き加える必要があります。
（例）
due://x-callback-url/add?title=[input]&x-source=workflow&x-success=workflow://
これはDueにinputを渡してアラーム登録が完了したあと、WorkflowのURLスキームを呼び出すというものです。
ごく普通の内容ですよね。
Workflowにコールバックするだけで作業が再開します。
※もちろん組み込むためには、呼び出すアプリ自体がコールバックのURLスキームに対応していることが前提です。
Extensionから実行すると処理が止まる
しかしExtensionから実行したワークフローはコールバックしても処理が止まってしまいます。
それはなぜか？
Extensionの処理は呼び出し元のアプリ側で作業しているためです。
TweetbotでExtensionを実行したなら、コールバックすべきはWorkflowアプリではなくTweetbotです。
ですから処理をスムーズに完了させるためにはこのような形をとります。
due://x-callback-url/add?title=[input]&x-source=workflow&x-success=tweebot://
アプリAから実行したときの流れは↓こんな感じ。
A → Extension（処理開始） → Due → コールバック → A（処理再開） → 完了
Aから呼び出したならAに戻る。これが鉄則です。
しかしこのやり方だとコールバック先が固定されており、アプリBから呼び出してもAが起動してしまいます。
B → Extension（処理開始） → Due → コールバック → A
Aに戻っても処理は完了しません。Bで実行した処理を再開するならBにコールバックする必要がある。
アプリA用、アプリB用にワークフローを別途用意しなくてはいけないんです。
しかしExtensionを実行する呼び出し元アプリごとに用意するなんてのはスマートではありませんよね。
ですのでこれをどのアプリから実行しても大丈夫なように汎用性を持たせてやります。
どこからでも実行可能なExtensionワークフローを作る
Extensionでの処理を継続させるためには呼び出し元アプリにコールバックさせる必要があると書きました。
それをクリアするために、Extensionでは処理をさせずに、常にWorkflowアプリ側で処理をさせます。
Extensionで行うのはWorkflowアプリ上で実行するワークフローを呼び出すだけ。
直接実行をするのではなくワンクッションを挟み、処理を実行するワークフローは別途用意するんです。
send to Due（Extensionで呼び出すのはこれ）
これはDue_mainというワークフローをWorkflowアプリで実行させるためのもので、Extensionから渡されるデータを引き継ぐためには&input=も必要です。
name=は実行したいワークフロー名を指定。（要URLエンコード）
Due_main側では通常の処理を行い、コールバックはWorkflowに固定されています。
A → Extension → Workflow（処理開始） → Due → コールバック → Workflow（処理再開） → 完了
これならAから呼び出しても、Bから呼び出しても、処理の実行やコールバック先はWorkflowですから、ちゃんと処理が完了します。
ポイントはワンクッションを入れること。
Workflow Typeもちゃんと設定してくださいね。
Workflow Typeとは
ワークフローには2種類あります。
Workflowアプリ内で実行する通常のフローがNormal。
Extensionから実行するタイプのものがAction Extension。
まぁそのまんまですね。
ワークフローを作ったのにExtensionに出てこない時は、ここがNormalになっているのが原因ですから確認してください。
要するにExtensionで表示させる必要のないものはNormalにしておけばよいです。
Workflow TypeがAction Extensionになっている場合にはもう1つ設定項目が増えます。
Acceptsという項目で、どの種類のExtensionから実行したときに表示させるかが選べます。
例えばブラウザ用のExtensionを写真アプリから実行しても意味ないですよね？
ブラウザから実行するだけならURLsにしておけばいい。
写真のExtensionならImages、文章ならTextと用途によって選びます。
まとめ
今回はURLスキームを自分で組み合わせてフローを作れる人のための解説なので、初心者にはちょっと関係ないものかもしれません。
ですがステップアップして自分でガシガシとワークフローを組み立てられるようになったら必ず必要になると思われますので、是非この記事のことを覚えておいてください。
ただこのままだと処理が完了してもWorkflowアプリが起動したままになるので、処理の最後にChoose from Menuで戻りたいアプリをいくつか指定しておくと1タップで元のアプリに戻れて便利です。
まぁ今回はそこまで解説しませんが、またいずれ。
こんな説明で伝わったでしょうか。
ちょっと不安もありますが、しっかりURLスキームを扱える人ならなんとか理解していただけたんじゃないかなと期待しておきます。
明日は前回の記事に載せ忘れたワークフローと、ちょっと初心者向けじゃなくて後回しにしたワークフローを紹介します。
個人的にはこれが一押しですのでチェックしてくれると嬉しい。
