nana music Tech Blog

株式会社nana music 開発チームのブログです。

AndroidアプリにFirebase AuthenticationによるTwitter認証を導入した話

はじめまして。
開発チームでAndroidエンジニアをしている松崎です。

今回は弊社のプロダクトである「nana」のAndroidアプリで初めて担当したFirebase Authenticationを使ったTwitter認証の機能を実装したお話をします。

なぜFirebase Authenticationを導入したのか

nanaでは以前からTwitter認証に Twitter Kit for Androidを使用していました。
しかしある時期から「Twitterアカウントでのログインに失敗する」というユーザからの問い合わせが増えてきました。
原因について調査を進めたものの有効な解決策が見つけられないまま時間が過ぎてしまっていたこと、Twitter Kit for Androidのサポートが2018年に終了しており使い続けることにリスクがあるだろうということで、思い切ってFirebase Authenticationを使った認証に移行することに決めました。
(当時ググってみた限り、Firebase Authenticationを使ったTwitter認証の事例記事はあまりなく、技術的な挑戦という側面もありました)

nanaの動作環境

本題に入る前に、nanaアプリの動作環境をご紹介します。

  • Development : 開発環境
  • Staging : リリース前テスト環境
  • Production : 本番

Androidアプリでは、それぞれの環境をGradleのProductFlavorで切り分けて管理しています。 また、それぞれの環境のアプリはデバッグアプリで1つのアプリ署名、リリースビルドで1つのアプリ署名をそれぞれ共通で使用しています。

導入

環境構築

Firebaseを初めて使用する場合、アプリへのSDKの追加やFirebaseへのアプリケーションの登録、Firebase AuthenticationのTwitter認証を有効にします。
また、Firebase Authenticationを使うためにはアプリ署名のフィンガープリントをFirebaseに登録する必要があります。
手順は下記のリファレンスを参考にしました。 firebase.google.com

nanaではすでにFirebaseを使用しており、3つの環境(Development Staging Production)のFirebaseプロジェクトの設定も概ね実施されていたため、Twitter認証の有効化のみ行いました。
(このとき、StagingのFirebaseプロジェクトもアプリ署名のフィンガープリントが表面上はきちんと登録されているように見えていました。しかしFirebaseの内部的には不正な登録状態になっており後述するStaging環境でTwitter認証できないという問題に直面します、、)

実装

基本的には下記のリファレンスに従って既存の処理を置き換えていくだけで、すぐに認証処理が実現できました。 firebase.google.com

ただし、サインアップ / ログイン時に任意のアカウントで認証したい、というユースケースを実現するには少し工夫する必要がありました。
以下に実現方法をご紹介していきます。

サインアップ / ログイン時に任意のアカウントで認証できるようにする

Firebase Authenticationは認証処理をChrome Custom Tabsによって行います。
最初にTwitterアカウントでサインアップ / ログインを行うと、その情報はChromeアプリに保存され以降の認証はその情報を自動的に使いまわして行われます。
そのため、アカウントが切り替えられないという事象に陥ります。
この事象の解決手段として、ログイン時にTwitter認証する際のOAuthProviderforce_loginというパラメータを使います。
force_logintrueに設定することで、ユーザにID/PWの入力を強制することができます

val oAuthProvider = OAuthProvider.newBuilder(TwitterAuthProvider.PROVIDER_ID)
            // アカウントを切り替えるため、ログイン時に過去の認証を使い回さず、毎回ログイン情報を入力させることを強制する
            .addCustomParameter("force_login", "true")
            .build()

firebaseAuth.startActivityForSignInWithProvider(this, oAuthProvider)
    .addOnSuccessListener(this::authSuccess)
    .addOnFailureListener(this::authError);

ハマったところ

Staging環境でTwitter認証できない

問題点

nanaではStagingProduction はアプリの applicationIdが同じになっています。
これはGoogle Play Billing Libraryを使った課金テストを Stagingアプリでも行えるように、アプリ作成当初からこのようになっていました。
この問題の真因は上述のStagingProductionapplicationIdが同一であることと、アプリ署名ファイルも同じものを使って署名していた点でした。
Firebaseではプロジェクトごとにアプリケーションを識別するために、applicationIdとアプリ署名の2つをセットで一意に識別しています。
そのため、複数のFirebaseプロジェクトに同一のapplicationIdとアプリ署名のセットを登録することはできません。
つまり、StagingapplicationIdもしくはアプリ署名をProductionと別のものにする必要があります。
上記の制約については、下記のリファレンスに記載されています。 support.google.com

補足

ここでの問題はもう1つあり、導入編の環境構築で記載したとおりStagingのFirebaseプロジェクトにはアプリ署名のフィンガープリントが表示されており正しく登録されているように見えていました。
しかし、google-services.jsonをダウンロードしてみるとAuthenticationの設定がなく正しく登録されていないような出力となっていました。
おそらく以前は、Firebaseでのアプリケーション登録時に同一のapplicationIdとアプリ署名を複数プロジェクトで登録できなくする入力チェックがなかったのではないかと思います。(現在は入力時にエラーが表示されます)

解決策

先述のとおりStagingは課金テストを行える必要があり、applicationIdを変更するとGoogle Play Consoleへの登録作業など必要な工程が増えるため、今回はアプリ署名をStaging専用のものを作成して使用することにしました。 アプリ署名を作成しCIの設定修正やFirebaseへの登録を行うことで正常にTwitter認証を行えるようになりました。

最後に

nanaでは、技術的な挑戦は歓迎されており今後も新しい技術に取り組んでいきます。
これからも得た知見などを発信していきたいと思います。
同じ課題に取り組まれる方の参考になれば幸いです。


最初から大きな案件にチャレンジさせてもらえる環境です! 一緒にチャンレジしたい方はぜひ一度お話を聞いてみませんか?

www.wantedly.com

nanaで使っている開発系サービスの紹介

開発チームのエンジニアリングマネージャーをしている佐々木です。

 今回はnanaで使っている開発系のツールやサービスを紹介します!

 

GitHub

github.com

言わずもがなのソースコード管理サービスです。全てのリポジトリを管理しています。

ZenHub

www.zenhub.com

プロジェクト管理サービスです。Githubとの相性がよく、Chromeにプラグインを入れて使っている方が多いです。Epic, SprintやReleaseに加えて、RoadmapやReport周りも徐々に使い始めてます。

Slack

slack.com

コミュニケーションサービスです。チーム単位、プロジェクト単位などで様々なチャンネルを使っています。絵文字やスタンプなどのフランクなコミュニケーションも歓迎しています。

Zoom

zoom.us

ビデオ通話サービです。社内で規定はないので、Google Meetを使う人もいますし1対1だとSlackコールを使う人など様々ですが、Zoomを利用しているケースが多いです。Slackと連携させて /zoom で部屋が作れるのが便利だなと思ってます。

Notion

www.notion.so

最近話題のなんでもできちゃうサービスです。nana musicでは、wikiや議事録をメインに、社内ポータルとしても利用しています。4月から導入してるのですが、徐々にドキュメントを書く文化というのが浸透してきてるなぁと実感しております!

AWS

aws.amazon.com

ご存知の通りのクラウドサービスです。nanaのサーバーサイドはAWSで動いています。EC2, ECS, S3, CloudFrontなど多くのサービスを利用しています。

GCP

cloud.google.com

こちらもご存知の通りのクラウドサービスです。BigQueryやDataProcを利用しています。

Redash

redash.io

BIサービスです。私自身前職で使っていましたが、nanaでは少し前に導入しました。これからどんどん使っていくことになると思っています。

Firebase

firebase.google.com

モバイル向けのプラットフォームです。CrashlyticsやRealtimeDatabase, App Distributionなどを利用しています。App Distributionは、iOSの社内アプリの配布で利用しています。Androidの社内アプリ配信は、後ほど消化するDeployGateを利用しています。

TravisCI

travis-ci.com

CIサービスです。APIとAndroidアプリで利用しています。

Bitrise

app.bitrise.io

CIサービスです。iOSアプリで利用しています。iOSアプリも元々はTravisを利用していたのですが、去年の11,12月ぐらいに金額が高くなったことをきっかけにBitriseに移行しました。

DeployGate

deploygate.com

App Distributionと同じくアプリの配布サービスです。Androidアプリの配布で利用しています。リモートの業務がメインの今はプロダクトオーナー・マネージャーの確認用にこまめに配布しています。CIと連動させて自動化している部分もあります。

 

開発として、プロダクトとしてのチャレンジはもちろん、本日紹介したサービス導入などでもチャレンジをどんどんしていきたいと思っています!

nanaで一緒にチャレンジしたい方は、ぜひ一度お話をしましょう!

www.wantedly.com

Bitrise上でXCUITestを動かすWorkflow

開発チームのiOSエンジニアをしている西山と申します!

今回は弊社で導入しているXCUITestをBitrise上で実行するための、Workflowを一部ご紹介したいと思います。

Device testing for iOS

XCUITestを複数の端末で実行するために、以下二つのWorkflowを採用しています。

  • Xcode Build for testing for iOS
  • iOS Device Testing f:id:nanamusic-tech:20210615101448p:plain

詳しくはDevice testing for iOSを参照ください。

Xcode Build for testing for iOS

Xcode Build for testing for iOSには大きく3つの変数を指定する必要があります。

  • Project (or Workspace) path
    • プロジェクトファイルのパスを指定します。
  • Scheme name
    • XCUITestを実行するスキームを指定します。
  • Configuration name
    • Build configurationを指定します 。(ex: Debug, Releaseなど)

以下のように環境変数に指定しておきます。 f:id:nanamusic-tech:20210615101710p:plain

iOS Device Testing

iOS Device Testingでは、UIテストを実行する端末を指定することができます。

Test devicesに所定のフォーマットで「端末、OS、言語、向き」を指定できます。

iphone8,14.1,ja,portrait
iphone11pro,14.1,ja,portrait
iphone7plus,14.1,ja,portrait

iOS Device Testingは、Firebase Test Labをベースとされているため、 指定できる最新の端末は、FirebaseのAvailable devices in Test Labを参照ください。

https://devcenter.bitrise.io/jp/testing/device-testing-for-ios/
あなたのアプリのテストはGoogleのデータセンター内にある本物のデバイス上で実行されます。

このように、よりユーザが操作するのに近い環境でテストを実行することができます。

現状だとiPhone11までだったりiOS14のものが少なかったりするので、種類が増えるのを期待したいですね。

Workflowを実施すると、Test Reportsのページから以下のように指定した端末の数だけテスト結果を確認することが可能になります。 f:id:nanamusic-tech:20210615101751p:plain

注意したい点

  • https://devcenter.bitrise.io/jp/testing/device-testing-for-ios/
    • 今回参考にした、Device testing for iOSの日本語ページには、「デバイスでのテストを許可する」の項目がありますが、こちらは現在削除されているようで、特段設定しなくてもDevice Testを実行することができました。(実際、英語ページ では、この項目は削除されています)
  • Provisioning Profile/Build Scheme/Build Configurationの環境を揃える
    • iOSエンジニアの方であれば当然の話かもしれませんが、本番/開発環境など、プロジェクト内で複数環境がある場合は、XCUITestを実施したい環境に全てが揃うように注意してください。
    • 私は1箇所勘違いしている点があり、ここで余計な時間を取られてしまいました。
  • 指定する端末について
    • 先述したように、テスト実施できる端末が豊富ではないので、これで十分か?の検討はしていただいた方が良いかと思います。
    • デバイスや、対応OSが廃止になることもあるので、定期的にデバイスリストについては確認する必要があります。こちら のページに削除予定の端末が掲載されています。

さいごに

nanaでは手動テストの負担を減らすべく、XCUITestの導入でクライアントテストの自動化を進めております。 これから導入を考えておられるプロジェクトの参考になればと思います。


nana musicでは、エンジニア/デザイナーを募集しております!

皆様のご応募をお待ちしております。

www.wantedly.com