React Nativeアプリで Sign in with Apple を実装する

こんにちは、アプリ開発担当のエモトです。待望の映画 SHIROBAKO が地方映画館でも上映される矢先、昨今の事情で休館になり、悲しみに暮れております。しかしながら、首都圏中心だったIT技術系の勉強会がリモート開催されるようになったりと、新しい世界を楽しもうと思った田舎民です。

さて、先日のアップデートでオーディオブックアプリは iOS / Android ともに Sign in with Apple に対応しました。今回は、その話を少ししたいと思います。Webでの話は こちら をご覧ください。

Sign in with Apple

Sign in with Apple は、アップル社が Apple ID を使った認証システムを提供します。ユーザーはパスワード不要で Face ID / Touch ID でアプリに登録やログインできる、サービス提供側は承認済みの Apple ID なのでメール確認不要など、様々な利点のもとで利用することができます。

React Nativeアプリで実装する

弊社サービスは自社の会員登録に加えて、Facebookでのログインをサポートしているので、Sign in with Apple は開発ガイドラインからも対応必須でした。アプリは React Native でクロスプラットフォーム開発を行っていますが、この実装は iOS / Android それぞれ別々に実装をしました。

iOS

こちらのライブラリ invertase/react-native-apple-authentication を使用しました。iOS の SDK をラッパーしているので、一連の認証フェーズは問題なく実装できました。手前味噌ですが、このライブラリのネイティブ部分のコードに不足があったので、私の方でPRを出して、コードを修正しました。

検証中に気づいた点として、シミュレーターでは Sign in with Apple はサポートされてないようなので、実際の認証を確認する場合は実機でデバッグするとよいです。また、当初は iPod touch で実機検証していたのですが、検証のたびに Apple ID のパスワードを入れるのが億劫でして、検証機を Touch ID がある iPhone 8 に入れ替えました。開発時は、利点でもある Touch ID や Face ID がある端末を利用するのがおすすめです。

Android

Android で Sign in with Apple を用いるのは個人的にもレアケースだと思います。弊サービスは iOS / Android / Web と複数のプラットフォームで提供しており、スマホは Android だけどタブレットは iPad などのケース（その反対も）も考えられるので、Android でも実装しました。

アップルが Android 用のネイティブ開発の SDK を用意していないのもあり、開発時点で React Native で利用できるライブラリは見つけることはできませんでした。そこで、直接認証URLにアクセスして、認証を行いました。

こちらのサイト Incorporating Sign in with Apple into Other Platforms / Send the Required Query Parameters を参考にして、https://appleid.apple.com/auth/authorize の認証URLを生成しました。redirect_uri に指定したURLに認証結果が戻ってくるので、それからユーザー情報を取得して、アプリを実装しました。

当たり前ですが、SDK で組んだ iOS に比べて、Android の方が手間がかかりました。

まとめ

実装自体は簡単にできると思います。しかしながら、名前が取得できるタイミングが最初の認証時のみなど、Sign in with Apple の仕様面を自社サービスに組み込むところに苦労しました。通常な使い方では問題ないと思いますが、開発時や、ユーザーがいったんサービスを退会してから再登録する場合など、いろいろ考えて作りました。

Sign in with Apple の既存アプリの対応締め切りが6月末と迫ってきています。まだ、React Native アプリで実装がまだの方はがんばっていきましょう。

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

• 株式会社オトバンク の採用・求人

お待ちしております。

PHPStan、phpstan-doctrine を 0.12 へと アップデートした

今週は仕事のメインリポジトリの
phpstanならびにphpstan-doctrineをやっと^0.12に上げたので気が強い

— sasezaki (@sasezaki) March 27, 2020

はじめに

弊社のサーバーサイド でのメインプロジェクトでは、過去のブログエントリにもあるように、PHP ならびにORMとしてDoctrine を導入しています。

• PHPStan で Doctrine Criteria で使ってるフィールドを検証できるようにした - OTOBANK Engineering Blog
  • https://engineering.otobank.co.jp/entry/2019/02/25/143224

そして PHPStan をQAでの主な静的解析として利用しており、コードレビュー時の負担を減らすため機械が指摘できることは極力機械で行えるように随時設定の見直し・チェック項目の追加などを行っています。

先月にはプロジェクトでの導入している PHPStan ならびにそのエクステンションのひとつである phpstan-doctrine のバージョンを ^0.12 にやっとのことでアップデートをしました。 その際の対応点と、バージョンをあげたことによる恩恵などについて記したいと思います。

PHPStan 0.12 ならびに phpstan-doctrine とは

PHPStanはよりfeatureを盛り込んだ0.12.0 が 去年12月に リリースされていました。

• PHPStan 0.12 Released! - Ondřej Mirtes - Medium
  • https://medium.com/@ondrejmirtes/phpstan-0-12-released-f1a88036535d
• PHPStan 0.12.0がリリースされました - 超PHPerになろう
  • https://www.phper.ninja/entry/2019/12/06/032456

とりわけ ジェネリクスのサポートは Doctrineのコレクションクラスを多用しているプロジェクトではより型を検査することに活躍できますね。 0.12 でのほかの feature としては以下が挙げられます。

“class-string” 擬似型 でのクラス文字列名のチェック

これは例えば

<?php
/**
 * @param class-string $className
 */
function foo(string $className): void { }

foo('DateTime');
foo(Bar::class); // Class Bar not found.

という風に、主にライブラリでクラス名を指定するようなケースでのミス防止につながります。

• https://phpstan.org/writing-php-code/phpdoc-types#class-string

phpstan/phpdoc-parserが0.4 にあがったことによる array-shapes (Object-like arrays) へのチェック

https://t.co/lqi4W7mQgo pic.twitter.com/laxIVr3ido

— sasezaki (@sasezaki) August 1, 2019

※ 正直なところとしては psalmですでにサポートされている array-shapes記法が PHPStan:0.11 ではエラー(Unexpected token)となってムムムと思ってました。

• https://phpstan.org/writing-php-code/phpdoc-types#array-shapes

「PHPでの型」と 「Doctrineでのカラム型」の不一致の判定

上述の OndrejMirtesのブログエントリ内にある 「Doctrine extension: compare property type against @ORM\Column definition」の記述の通り、Doctrineで定義されている型と@var アノテーションでのプロパティ型に不一致がある場合警告してくれるようになりました。これは ^0.12 に上げることで最も大きい恩恵と言えるでしょう。

これは主に、nullable=true とカラムを定義していたにも関わらず、@var アノテーションにnullableなユニオン型チェックを定義していない検出に役立ちました。

また、下記のようなdeciaml定義をしたにも関わらず int を記述しているようなケースについても

    /**
     * @var int
     * @ORM\Column(name="latitude", type="decimal")
     */
    private $latitude;

type mapping mismatch\\: database can contain string but property expects int と警告で気づけるようになりました。

また、

<?php
class User
{
    /**
     * @var CreditCard
     *
     * @ORM\OneToOne(targetEntity="CreditCard", mappedBy="user", cascade={"persist","remove"})
     */
    private $creditCard;

のような nullがありうる OneToOneなどのアソシエーションへも

 ------ ----------------------------------------------------------------------------------------------------------
  Line   User.php                                                                                                 
 ------ ----------------------------------------------------------------------------------------------------------
  123    Property User::$creditCard type mapping mismatch: database can contain
         CreditCard|null but property expects CreditCard.
 ------ ----------------------------------------------------------------------------------------------------------

と警告がでるようになりました。

^0.12 に上げるためにしたこと、併せて行ったこと

otobank/phpstan-doctrine-criteria をアップデート

PHPStan 0.12 への変更に追従しているかを確証するために各ユニットテストの追加と 依存する phpstanならびにphpstan-doctrineのバージョンを 0.12 系に上げました。 https://github.com/otobank/phpstan-doctrine-criteria/pull/1

不足していたプロパティ指定の追加。

phpstan-doctrineを 0.12 に上げた際に、主に対応量が多かったのは、下記のような OneToManyなプロパティについて、

<?php
class Audiobook
{

    /**
     * @var \Doctrine\Common\Collections\Collection
     *
     * @ORM\OneToMany(targetEntity="Artwork", mappedBy="audiobook", cascade={"persist","remove"}, orphanRemoval=true)
     */
    private $artworks;

 ------ -----------------------------------------------------------------------------------------------------------
  Line   Audiobook.php                                                                                             
 ------ -----------------------------------------------------------------------------------------------------------
  217    Property Audiobook::$artworks type mapping mismatch: property
         can contain Doctrine\Common\Collections\Collection but database expects
         Doctrine\Common\Collections\Collection&iterable<Artwork>.
 ------ -----------------------------------------------------------------------------------------------------------

と警告が出る点でした。 これはもちろんそのプロパティを参照するさいに(foreachで回す場合など)はどのエンテイティを取得しているか必要となるため、これは警告通り iterable<エンテイティクラス>なユニオン指定を地道に追加していきました。

<?php
class Audiobook
{

    /**
     * @var \Doctrine\Common\Collections\Collection&iterable<Artwork>
     *
     * @ORM\OneToMany(targetEntity="Artwork", mappedBy="audiobook", cascade={"persist","remove"}, orphanRemoval=true)
     */
    private $artworks;

プロパティタイプヒントを必須に

That should still be declared via `var` docblock annotation.

— Can't fix stupid, can't quarantine it either. (@Ocramius) October 11, 2018

上述の"「PHPでの型」と 「Doctrineでのカラム型」の不一致の判定"は、各プロパティの型が検出できなければいけません。PHPStan でのlevel 6 では(主にアノテーションでの)タイプヒントに関しての各ルールが追加され、この中の MissingPropertyTypehintRule によってタイプヒント指定されているかを検出できます。

• https://github.com/phpstan/phpstan-src/blob/0.12.19/conf/config.level6.neon

また、phpstan.neonでのパラメータで inferPrivatePropertyTypeFromConstructorをtrueにすればコンストラクタでの型指定からプロパティの型補足する方法もあります。 しかしながら、現在のコードベースでのタイプヒント全般については、継続的に都度記述を行って改善している段階であります。

そのため、プロパティタイプでの型宣言を必須とするチェックには、PHP_CodeSniffer 用の追加ルール slevomat/coding-standard での SlevomatCodingStandard.TypeHints.PropertyTypeHint Sniff を用いて コーディング規約チェックとして検出するようにしました。

まとめ

この記事では、PHPStan 0.12 を導入した点でも特に、phpstan-doctrine での利点/対応点についてふれました。 ここ最近の PHP静的解析シーンでの注目は、強力な擬似型のサポートであるわけですが、今回メインプロジェクトにて PHPStanを0.12に上げたことにより、その効果によりバグの減少やテストの強化につながる土台を整えらえて安堵しています。

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で再生制御を行いました。

最も苦労した点の１つは、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開発に少しでも興味があれば、是非どうぞ。

• 株式会社オトバンク の採用・求人

お待ちしております。