アプリエンジニアの山口です。先日、大阪港にて一般公開された護衛艦かがに乗艦しました。女性の海上自衛官)のみなさまが一様にべっぴんさん揃いだったことも驚きでしたが、一番驚いたのが、艦内便所にウォッシュレットがついていたことです。便座足台もついており、手洗いの脇にはハンドドライヤーまでついていました。年でここまで進化を遂げたとは思いもしませんでした。使用後の便器洗浄自体は相変わらずバルブをセルフでしたが。ついてさて、昨今ではスマホアプリといえばサーバー連携ありきのものがほとんどだと思います。アプリ開発中はサーバーも開発中だったりして、ダミーの応答を返す仕組みをつかってアプリ開発をすすめることが多いと思います。使って実装する例をご紹介したいと思います。スタブを作ることは可能です。自由に使えちゃいます。(コードは提示しませんので適宜読み替えてください。クラスを継承したクラスを書いて、必要なメソッドをオーバーライドしていきます。返すとインスタンス化され、プロキシサーバーのように通信をハンドリングできるようになります。実際の通信処理を置き換えることができます。実行させたままにしないと処理が中断されるおそれがあるため、先頭の方に下記のように記述しておきます。継承したクラスを実装さて、本題ですが、下記のように有効化するコードを書きます。}次にフックするデータを登録します。俯瞰できるように定義はまとめておきたいのでこの構造にしています。ここでは省略していますが、パラメーターによってはフックする/しないを切り分け可能です。返す、といった使い方もできます。メソッド群を実装していきます。リクエストの正規化が必要であれば加工して返す。キャッシュのための比較用として使われる。先ほど登録したフック定義を収める容れ物です。フックしたときに呼ばれる。レスポンスデータを返す。フックしたときに呼ばれる。エラーを返したい場合に使用する。レスポンスの定義も一覧にしておきたいため、別に分けています。"ただいまメンテナンス中です。"お知らせその1です。"お知らせその2です。エリアにまで及ぶ一方、記号が含まれていない。カバーされているが、「&」や「/」などといった、エンコードが必要な要素まで含まれている。}}おまけのユーティリティ本筋とは関係ありませんが、配列要素を順番に実行するようなものがあると検証に便利なので定義しています。そのまま使ってしまうと、通信処理が終わる前に並列実行されるおそれがあり、検証の妨げになります。それぞれ成功するか見てみます。