OTOBANK Engineering Blog

オトバンクはコンテンツが大好きなエンジニアを募集しています!

React NativeアプリでSiri Media Intentを実装した話

初めまして、アプリ開発を担当している エモト と申します。手元にSHIROBAKOのムビチケがあるのに、昨今の事情で映画館に行けず、モヤモヤしております。昨年秋に入社して、いつかはブログを書こうと思って気付いたら今日となりました。よろしくお願いします。

さて昨年末、弊社のiOSアプリは Siri Media Intents に対応しました。

「Hey Siri, {作品名}をオーディオブックで再生して」

と呼びかけると、Siri経由でアプリのライブラリ内にあるオーディオブックが再生されます。ぜひお試しください。

弊アプリは、React Native(以降、RN)でアプリ開発を行っています。クロスプラットフォーム開発のRNでSiriが実装できるの!?と思う方もいるかと思います。RNでのSiri開発を少し話したいと思います。

なお、以降文中のネイティブ開発は、Xcodeを使ったSwiftやObjective-Cでのアプリ開発を指します。

Siri Media Intents と React Native

一般的なネイティブ開発での Siri Media Intents の実装は、Siriが命令を受けると、Intent側の handle(intent:completion:) からアプリ側のメソッド application(_:handle:completionHandler:) が呼ばれます。そのメソッド内でアプリ側の処理(今回はオーディオブックの再生)を行い、Siriへ完了コールバックを送ります。ここで、弊社アプリはRNを採用しているため、RN側で処理を行う必要があります。

RNには、SwiftやObjective-Cで書かれたネイティブモジュールを用いて、ネイティブ 側とやりとりできる機能があります。それを利用して、Siriから受けた情報をRNに送り、RNで再生制御を行いました。

f:id:mitsuharu_e:20200401134736p:plain

最も苦労した点の1つは、RN側の再生処理の結果を application(_:handle:completionHandler:) の中で受け取らなといけないことです。ネイティブからRNへにイベントを送る処理は情報を送るだけで、再生完了コールバックのデリゲートやクロージャを設定することはできません。あまりスマートではないですが、RN側で処理が完了したらネイティブ側に完了フラグを通知する、ネイティブ側はそのフラグが立つまで待つというアプローチを取りました。

// React-Nativeからの完了を受け取る
var isSucceededFromRN: Bool?

@objc( SiriCtrl )
class SiriCtrl: RCTEventEmitter {
}

extension SiriCtrl {

  // React-NativeからNative methodとして、Intentの完了メソッドを呼ぶ
  @objc(completeSiriHandler:)
  func completeSiriHandler(isSucceeded: Bool) {
    DispatchQueue.global().async {
      isSucceededFromRN = isSucceeded
    }
  }
  
   /**
   AppDelegate の application(_:handle:completionHandler:) 
   の中で用いるメソッド
   */
  func application(_ application: UIApplication,
                   handle intent: INIntent,
                   completionHandler: @escaping (INIntentResponse) -> Void) {
    if #available(iOS 13.0, *) {
      guard
        let playMediaIntent = intent as? INPlayMediaIntent,
        let mediaItem = playMediaIntent.mediaItems?.first,
        let title = mediaItem.title
        else {
          completionHandler(INPlayMediaIntentResponse(code: .failure,
                                                      userActivity: nil))
          return
      }

      // 完了判定フラグを初期化する
      isSucceededFromRN = nil

      // React Nativeに再生イベントを投げる
      self.sendMediaInfoToReactNative(title: title)

      // RNから完了判定が帰ってくるまで待つ
      self.waitAsyncCallback({
        isSucceededFromRN == nil
      }) {
        var code: INPlayMediaIntentResponseCode = .failureRestrictedContent
        if let result = isSucceededFromRN, result == true {
          code = .success
        }
        completionHandler(INPlayMediaIntentResponse(code: code,
                                                    userActivity: nil))
      }
    }
  }
}

extension NSObject {

  /**
   処理完了を待ってから、後続処理を行う
   */
  func waitAsyncCallback(_ waitContinuation: @escaping (() -> Bool),
                         completion: @escaping (() -> Void)) {
    var wait = waitContinuation()
    let semaphore = DispatchSemaphore(value: 0)
    DispatchQueue.global().async {
      while wait {
        DispatchQueue.main.async {
          wait = waitContinuation()
          semaphore.signal()
        }
        semaphore.wait()
        Thread.sleep(forTimeInterval: 0.01)
      }
      DispatchQueue.main.async {
        completion()
      }
    }
  }
}

非同期処理の待ち処理は、こちらの記事 【Swift 3】処理の完了を待ってから後続処理を行う - Qiita を参考にしました。ありがとうございます。

まとめ

React Nativeと聞くと、SwiftやKotlinなどのネイティブコードは不要のイメージがあるかもしれません(私も最初はそうでした)。しかしながら、今回のような固有機能の実装時には適宜ネイティブコードを使用しています。

最後に、オトバンクではエンジニアを募集中です。もし、日頃はSwiftやKotlinを書かれてる方でも、オーディオブックや、React Native開発に少しでも興味があれば、是非どうぞ。

お待ちしております。

Sign In with Apple サーバ実装時に悩んだポイント〜名前・emailが取得できない編〜

こんにちは。 コロナウイルス対策で引きこもり属性が高まっているサーバエンジニアyukimuraです。

突然ですが、アプリのソーシャルログインといえば何が思い浮かびますか?


Facebook?


Google?


Apple?





あれ、Appleのサインインボタンってあんまり見たことないな〜と思った方はいないでしょうか?


それもその筈、Appleのソーシャルログインは、2019年6月3日にAppleが発表した新機能なんです。

このAppleによるソーシャルログイン、「Sign In with Apple」ですが、既にApple以外のソーシャルログインを実装しているIOSアプリは、2020年6月30日までに実装する必要があります。(2020/3/30現在)
※ 改定の可能性があるため、最新の情報はAppleのガイドラインを確認してくださいね。

ですので今後、Sign In with Appleを実装したアプリが増えていくことと思います!

弊社のアプリaudiobook.jpもただいまSign In with Appleを絶賛実装中です😁
audiobook.jpにはIOSアプリ・androidアプリ・webアプリがありますので、それぞれに実装を行なっています。 私はサーバサイドエンジニアとして認証api・webアプリのサインイン機能の実装に携わっております。

これから実装する方もいらっしゃるのではと思いますので、私が実装時に悩んだ内容を残しておこうと思います!

名前・メールアドレスが取得できず困る

まず、webアプリケーションにsiwaを実装する場合、認証用のURLを用意する必要があります。 (Sign In with Apple JSを利用する場合はパラメータをセットするだけで自動的にURLが生成されますが、利用しない想定です。)

URLに必要なクエリパラメータについては公式ページに記載があります。 https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/incorporating_sign_in_with_apple_into_other_platforms

さて、URLを組み立ててAppleの認証画面で認証すると、認証したユーザの名前とメールアドレスが取得できるはず・・。

ということで以下のようなURLを作成して試してみました。

https://appleid.apple.com/auth/authorize

クエリパラメータ
  client_id = xxx (アプリ毎に異なるid)
  redirect_uri = xxx
  response_type = code id_token
  response_mode = form_post

認証の結果、以下認可codeとIDトークンを取得できました。

code: xxxxxxx
id_token:yyyyyy

取得したIDトークンをデコードすると・・(値はサンプルです)

{
  "iss": "https://appleid.apple.com",
  "aud": "xxx",
  "exp": 1234567890,
  "iat": 1234567890,
  "sub": "xxx",
  "c_hash": "123456",
  "auth_time": 1234567890,
  "nonce_supported": true
}

email・名前は含まれていませんね。 よくURLを見てみると、scopeを設定していなかったためscopeを指定して再試行します・・

https://appleid.apple.com/auth/authorize

クエリパラメータ
  client_id = xxx (アプリ毎に異なるid)
  redirect_uri = xxx
  response_type = code id_token
  response_mode = form_post
  scope = email name

しかしレスポンスされるデータ構造には変化がなく、email・名前が取得できません・・!

原因

Appleとの初回認証時にscopeを設定しておく必要がありました。 2回目以降の認証だと、scopeを設定しても効果はありません。

初回認証時にscopeを設定している場合は以下のような結果が取得できます。

code: xxxxxxx
id_token:yyyyyy
user: {
  "name":{"firstName":"太郎","lastName":"音羽"},
   "email":"otohatarou@example.com"
}

userというフィールドが追加され、名前とemailが取得できました!

取得したIDトークンをデコードすると・・(値はサンプルです)

{
  "iss": "https://appleid.apple.com",
  "aud": "xxx",
  "exp": 1234567890,
  "iat": 1234567890,
  "sub": "xxx",
  "c_hash": "123456",
  "email": "otohatarou@example.com",
  "email_verified": "true",
  "auth_time": 1234567890,
  "nonce_supported": true
}

IDトークンにもemailが含まれています。 なお、Appleで初回認証時にメールの共有・非公開を選択できますが、共有を選択した場合にはemail_verifiedtrue、非公開を選択した場合にはfalseになります。

注意点として、このscopeを設定していた場合でも2回目以降の認証の場合userフィールドは取得できません・・。 2回目以降でもemailはIDトークンに含まれているため、2回目以降で取得可能なのはemailのみとなります。

ユーザが初回認証後操作をキャンセルして再認証した場合、名前は取得できなくなりますので、名前を取得できないことも考慮して実装を行う必要があります。
Facebookのようにユーザ情報を取得するUserInfo Endpointがあれば良いのですが、今のところ残念ながらそのようなapiは用意されていないんですよね・・。

再度初回認証を試したい場合

AppleIDのアカウントページから自分のアプリの紐付け情報を削除すれば、再度初回認証の確認ができます。 https://appleid.apple.com/#!&page=signin

ログイン後、以下手順で紐付け情報を削除できます。

> 「セキュリティ」を選択
> 「Apple IDを使用しているAppとWebサイトの管理… 」を選択
> ご自分のアプリを選択
> 「Apple Idの使用を停止」をクリック

終わりに

ソーシャルログインの実装に慣れている方であればすぐに原因が分かる内容かもしれませんが、認証系の実装は初めてだったため原因が分からず苦労しました・・!

この内容がお役に立てたようでしたら嬉しいです😊

どや会!

はじめまして。9月にオトバンクに入社しました、エンジニアのyukimuraです。 入社してもうすぐで半年・・時間の流れが本当に早いですね〜。

さて、オトバンクではリモートワークが推奨されており、エンジニアもリモートワークで働いている方が多いです。 普段はslackでコミュニケーションをとっていますが、月一くらいは顔を合わせてわいわいしたいよね・・

ということで、 開発チームで過去に行なっていた「どや会」が復活しました😄

今回はどや会とは何?というところから、どや会の様子を紹介していきたいと思います。

どや会とは?

  • 月に1回、月末に開催
  • 開発メンバー全員でご飯を食べながら、今月のリリースをふりかえります
  • 1ヶ月の働きをねぎらうべく、毎回おいしいご飯を用意しています

どや会のアジェンダ

  1. 乾杯
  2. 今月のリリース共有
  3. 雑談 「どや会」は乾杯からはじまります! リリースの共有では、GithubのcloseされたPullRequest一覧と事前資料をベースに行います。 事前資料には自主的に書き込む項目があり、「これはイケてるっしょ!」というものを各自書き込み&発表(どやぁ)してもらいます。

9月のどや会 〜第1回目〜

第1回目のどや会は社内で開催しました!

乾杯の後はご飯を食べながら各自今月のリリース内容等をどやぁしていきます。
私は入社したてで分からない内容もありましたが、先輩方のどやぁを聞きながら一緒に分からない事を教えていただき勉強になりました!

気付いたら途中からゲーム大会に😎

10月のどや会 〜スーパー銭湯回〜

10月は会社近くの「らくスパ」というスーパー銭湯で、リモートワーク & どや会を行いました。

スーパー銭湯ですが、コワーキングスペースがあり仕事ができます!

f:id:yukimura0301:20200123205124j:plain

どや会はイベントルームにて。

f:id:yukimura0301:20200123205651j:plain

各自好きなドリンクを頼んで乾杯!
どでかハイボールを飲む方もいれば、かわいい( ? )メロンソーダを飲む方も🐸

f:id:yukimura0301:20200124123219j:plainf:id:yukimura0301:20200124123225j:plain


仕事が終わったら一汗流して美味しいものを食べる・・最高でした〜😇

11月のどや会 〜リモート勉強会〜

11月のどや会は社内で行いました。
どやぁ!が終わった後、LT勉強会「kyotoLT」さんに参加させていただきました。
「kyotoLT」さんは京都で開催されているLT形式の勉強会です。

kyotolt.connpass.com

オトバンクの事務所は東京なので直接参加はできませんが、京都の会場にリモート接続して参加させていただきました。
お互いリモート接続は初の試みでしたが、無事接続できて沢山勉強になるお話を聴くことができました!

オトバンク からは @kalibora さんが発表してくれました。

こちらは発表の資料です。
オトバンク はAPIの開発にswagger(OpenAPI)、静的解析ツールとしてphpstanを利用しております。
どのように利用しているか気になる方は是非資料を読んでみてください!
私はうっかりミスが多いのでphpstanにはいつも助けられています😅

speakerdeck.com

kyotoLTの皆さん、ありがとうございました!

1月のどや会 〜ピザ回〜

1月はどやぁ!の後はピザを食べながらゆる〜く雑談。
エンジニア以外の方々も集まってくれて楽しかったです!

まとめ

どや会は普段リモートワークで交流が少ないメンバーともお話ができて良いイベントだなと思います。その回の幹事によって方向性も違うため毎回面白いですね!

1月・2月は大型の開発案件があり開発チームは忙しくなりますが、次回のどや会を楽しみに頑張っていきましょう〜。