2023-03-31

コネヒト株式会社は PHPerKaigi 2023 にシルバースポンサーとして参加しました！スポンサーブース準備と当日の様子をご紹介します！

こんにちは！@TOC です。

コネヒトはPHPerKaigi 2023にシルバースポンサーとして協賛しました。

PHPerKaigi はオフライン開催ということで弊社も久しぶりにスポンサーブース出しました。本ブログではスポンサーブースの準備と当日の様子について、@TOC, @ryo がご紹介しようと思います！

PHPerKaigi とは
スポンサーブースを出して盛り上げよう！
当日はどんな感じだったか
PHPerKaigiを終えて

PHPerKaigi とは

PHPerKaigi 2023 は2023年3月23日（木）〜3月25日（土）に開催されたイベントで、弊社はシルバースポンサーとして協賛させていただきました。

スポンサーブースを出して盛り上げよう！

最近はオフラインでの技術イベントも増えてきて、実際に足を運ぶと活気あるな〜って気持ちになりますね🙌

今回 PHPerKaigi もオフラインで行うということでスポンサーブースを出すことにチャレンジすることになりました。

とはいえ久しぶりのスポンサーブースということでどういう企画にするのがいいのか、をまずは話し合うことになりました。

案を出してみる

まずはみんなで案を出してみようということで、有志で集まった人たちで案だしをしました。

出した案の中から投票を行い、主に下記３つに票が集まりました。

自社のプロダクトを知ってもらうためにママリドリルを解いてもらう
自動テストどのくらいやってるか聞く
PHP のバージョンを聞く

PHP のバージョンは他のブースと被りそうだよね、といった会話もあり、自社プロダクトを知ってもらう企画を押し出す方向性をまずは考えてみました。

ママリドリルって何？

今回自社のプロダクトであるママリを知ってもらう企画としてママリドリルを提案しました。

ママリドリルは弊社のオンボーディングで使われており、ママリの「温かい」コミュニティを作るためのちょっとした仕掛けをクイズ形式で解いてもらい、自社のプロダクトの理解を深める取り組みです。

僕はこのママリドリルがすごい好きで、「ママリももちろんだけど、この取り組みをもっと知ってもらいたい！」という気持ちでいたので、採用されてワクワクでした。

やるならママリ色を全面に出そうと、めちゃめちゃ可愛いスライドを作って臨みました。

肝心の中身は…また別の場所でもママリドリルを使ってママリを知ってもらう機会を作ろうと思うので、その時のお楽しみに…！

普段のシステム開発についても聞いてみた

ママリドリルだけだと一人一人のコミュニケーションは濃くできるけど、答える側のハードルも高いよね、と思ったので、ライトに答えることができる下記2つのアンケートも用意しました。

どんなテストを書いてますか？
どんなエラー監視をしていますか？

このように厚くコミュニケーションが取れるコンテンツとライトに答えられるコンテンツの２パターンを用意する設計にしました。

より楽しく取り組むために

せっかく回答してくれたのに「ありがとうございました」だけで終わったらなんか寂しいので、コンテンツに参加してもらうとノベルティのチロルチョコをもらえるようにしました。

今回4種類のチロルチョコを用意していたので、

ちょっと時間がかかるママリドリルを答えたら3個
ライトに答えられるアンケートは1個

→どっちも答えると全種類制覇できます！

という流れを作ってどっちのコンテンツも楽しく取り組めるような形にしてみました。

（ただ、今回の反省点は全種類同じ味になってしまったことで少しがっかりさせてしまったところですね…次回はいろんな味を用意したい！）

改めて本物を当日見たら「いや、これは全部欲しいでしょ！」って気持ちになりました⤴️

こんな感じで準備を進めていて、絶対良いコンテンツができた！っていう気持ちと、実際楽しんでくれるのかな…っていう不安を抱えながら当日を迎えました。

当日はどんな感じだったか

当日は練馬の会場に9時に集合しスポンサーブースの設営をしていきました。コネヒトは机の後ろにコネヒト横断幕を置かせていただき目立ちまくってたような気がします笑。

周りのスポンサーの方達も設営の準備を進めていて久々のオフライン開催に熱気が高まっていくのを感じました…！！

PHPerKaigi が始まってからはたくさんの PHPer の方々がコネヒトのブースに来ていただき、ママリドリルやシステム開発のアンケートに答えていただきチロルチョコがどんどんはけていきました！

そして気になるアンケート結果はこちら！！

監視もテストも日常的に行っている企業さんが多く印象的でした。

参加していただいた皆さんにはママリドリルを解いた後にママリのプロダクトやその工夫について話したり、他にもPHPの話や普段の開発の事について沢山コミュニケーションが取れて非常に有意義な時間となりました。

中には弊社のテックブログが参考になった、というお声もいただき、とても嬉しい限りでした。

参加していただいた皆様ありがとうございました！！

コネヒトの参加メンバーもブースの案内をしつつ、気になる登壇やLTに出向いて知識やノウハウを吸収させていただきました！

PHPerKaigiを終えて

ブース出展のノウハウがあまり無い中での手探りでの出展でしたが、参加していただいた PHPer の方達に楽しんでいただき大満足の1日でした!

これからも技術コミュニティへの貢献をしていき、盛り上げていきたいと思います！

2023-03-27

GitHub ActionsからマニュアルトリガーでBitriseを動かす方法

Bitrise iOS

はじめに

コネヒトでiOSエンジニアをやっているYoshitakaです。

先日、iOSアプリ開発のCI/CD環境を改善するため、これまで一部ローカルから実行していたfastlaneの処理をGitHub ActionsをトリガーにしてBitrise上で実行するように対応したので、一部内容を紹介したいと思います。

改善したこと

ママリのiOSアプリ開発では主にBitrise, fastlane（一部GitHub Actions）を使ってCI/CD環境を構築しております。

Bitrise(fastlane)で実行しているワークフローは以下の通りです。

Testの実行
App Distributionへの配布
App Store Connectへのデプロイ
Developer Accountへのデバイス追加

今回の改善ではこれまでローカルで実行していたデバイス追加のワークフローをGitHub ActionsでトリガーしてBitrise上で実行するように対応しました。

この対応によりローカル実行ではApple IDの認証で2FA認証を使っていましたが、Bitrise経由で実行することで推奨されているApp Store Connect API keyを使った認証に切り替えることができました。

やったこと

改善前はfastlaneをローカルから直接実行し対話型でデバイス名とUDIDを入力してデバイス追加をしていました。

  desc "Add test device and update provisioning profile"
  lane :add_device do
    name = UI.ask('Name of device:')
    udid = UI.ask('UDID of device:')
    register_devices(devices: {name => udid})

    match(type: "development", readonly: false, force: true)
  end

↓

これを GitHub Actions → Bitrise → fastlane と実行するようにします。

GitHub Actions → fastlane としても動くのですが、 App Store Connect API keyの情報は現状Bitriseでのみ使っており、一元化管理したいため今回はBitrise上で動かすようにしています。

GitHub Actions

GitHub Actionsのトリガー部分は、workflow_dispatchのinputsを設定することでデバイス名とUDIDを入力できるようにします。

こちらがGitHub ActionsからBitriseをマニュアルトリガーするworkflowです。

on:
  workflow_dispatch:
    inputs:
      device_name:
        description: input device name
        required: true
        type: string
      device_udid:
        description: input device udid
        required: true
        type: string

jobs:
  add_device:
    runs-on: ubuntu-latest
    steps:
    - name: Trigger Bitrise workflow
      env:
        bitrise_api_key: ${{ secrets.BITRISE_API_TOKEN }}
        bitrise_app_slug: "abc0123456789"
      run: |
        curl -H "Authorization: $bitrise_api_key" https://api.bitrise.io/v0.1/apps/$bitrise_app_slug/builds -d \
        '{
          "build_params":{
            "environments":[ 
                {
                    "mapped_to":"DEVICE_NAME",
                    "value":"${{ inputs.device_name }}", 
                    "is_expand":false
                }, 
                {
                    "mapped_to":"DEVICE_UDID",
                    "value":"${{ inputs.device_udid }}", 
                    "is_expand":false
                 }
            ],
            "workflow_id":"add_device"
          },
          "hook_info":{
            "type":"bitrise"
          }
        }'

BitriseのworkflowをGitHub ActionsからトリガーするためBitrise APIを使います。

devcenter.bitrise.io

手順は以下の通り

Bitrise API Keyを発行してGitHubのSecretsに保存
bitrise_api_key、bitrise_app_slug、workflow_idをcurlコマンドに追加
inputsで入力した値はBitrise側で使えるようenvironmentsに追加

bitrise_app_slugはBitriseの対象のAPPページのURLで確認できます。 /app/abc0123456789 ← app/から後の値

Bitrise API KeyはBitriseのProfile Settings→Security→Create tokenから発行できます。

workflow_idはbitrise.ymlに定義したworkflow名になります。

デバイス名とUDIDをBitrise側に渡してfastlaneで使う方法は、公式ドキュメントを参考にしました。

Bitrise

BitriseではFastfileに定義したデバイス追加のlane(add_device)を実行、結果をslack通知しています。

slack通知の細かい設定方法は公式ドキュメントを確認しても見つからずでしたが、 inputsの値を指定することでconfigが変わり通知内容をカスタマイズできました。configの値はBitriseのLogを見ることで確認できます。

  add_device:
    meta:
      bitrise.io:
        stack: osx-xcode-14.2.x-ventura
    steps:
    - activate-ssh-key@4:
        run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
    - git-clone@6: {}
    - cache-pull@2: {}
    - fastlane@2:
        title: fastlane add_device
        inputs:
        - lane: ios add_device
    - slack@3:
        title: Slack Notification
        is_always_run: true
        inputs:
        - webhook_url: $SLACK_WEBHOOK_URL
        - title: "Add Device"
        - message: "デバイスを追加しました"
        - message_on_error: "デバイス追加に失敗しました"
    description: fastlane add_device_via_github_actionsを実行するワークフロー

fastlane

GitHub Actionsで入力したデバイス名とUDIDはENV["DEVICE_NAME"],ENV["DEVICE_UDID"]とすることで取得できました。

  desc "Add test device and update provisioning profile"
  lane :add_device do
    app_store_connect_api_key(
      key_id: ENV["ASC_KEY_ID"],
      issuer_id: ENV["ASC_ISSUER_ID"],
      key_content: ENV["ASC_KEY_CONTENT"],
      in_house: false
    )
    register_devices(devices: {ENV["DEVICE_NAME"] => ENV["DEVICE_UDID"]})

    match(type: "development", force_for_new_devices: true)
  end

認証はApp Store Connect API keyで行うためapp_store_connect_api_keyを使います。

今回は既存でapp_store_connect_api_keyを使っていたので対応してませんが、新しく追加する場合はApp Store ConsoleからAPI Keyを発行してBitrise側のSecretsに保存しておく必要があります。

保存した値はENV["ASC_KEY_ID"],ENV["ASC_ISSUER_ID"], ENV["ASC_KEY_CONTENT"]のような形で取得できるのでこれをfastlaneのapp_store_connect_api_keyに渡してあげることでAPI Keyでの認証が可能になります。

デバイスの追加はfastlaneのregister_devicesにデバイス名とUDIDを渡してあげることで実現できます。

またデバイス追加後のプロファイルの更新ではmatch(type: "development", force_for_new_devices: true)とオプションを追加することで不要な更新をしないようにしました。

docs.fastlane.tools

まとめ

今回は元々あったワークフローのトリガー部分を変更しただけの改善でしたが、Bitriseやfastlaneのドキュメントを読むと他にできることがたくさんあるようなので、引き続き開発業務と並行してCI/CD環境の改善にも力を入れていきたいと思います！

参考

docs.github.com

devcenter.bitrise.io

2023-03-23

ママリ iOSアプリの2023年3月現在の開発環境

iOS

2023年3月現在のママリのiOSアプリは開発環境について紹介します。

言語

100% Swiftで、以前はObjective-Cのコードもありましたが、全てSwiftに書き換えました。

iOSのサポート範囲

iOS14以上としています。4/10以降は14.5以上に変更予定です。（iOS14.0~14.4でSwiftUIの挙動の違いがあるためサポート範囲外としました）

使っている主なフレームワークやライブラリ

主に以下のフレームワークやライブラリを利用しています。

UIKit, SwiftUI
RxSwift, Combine
Realm
Firebase

以前はUIKitとRxSwiftを使っていましたが、新しい画面についてはSwiftUIとCombineを使用する方針で開発しています。ただし、SwiftUIで実装する際に特殊な方法が必要であれば、新たな負債を作らないためにUIKitで実装する方針です。

アプリ内でデータ永続化のためにRealmを利用していますが、ママリは基本的にWeb APIから情報を取得して表示することがメインであり、Realmは軽量な利用に留めています。

Firebaseは、分析、ABテスト、クラッシュ検知など多様な用途で使用しています。

アーキテクチャ

RxSwiftが主となっているため、MVVMになっています。 SwiftUI導入時にTCAも検討しましたが、特定のFrameworkに強い依存をしたくなかったのもあり、一旦見送っています。ただし、今後課題が出てきた場合は再考していく予定です。

Model部分を別モジュールとして切り分けています。これについて詳しくはこちらのブログをご覧ください。 tech.connehito.com

ツール

swift-formatやSwiftLintが開発中に自動で実行されるようにしています。

Renovateをつかってライブラリを定期的にアップデートする仕組みを導入しています。

iOSエンジニアの数は2名で、project fileでコンフリクトすることはあまりないためXcodeGenは導入していません。

デザイナーとのデザインのやりとりはFigmaをつかっています。

テスト

Quick/Nimbleを使ってユニットテストを書いています。

全てにテストを書いているわけではなく、APIの通信周りは必須、ViewModelやModelは推奨としています。

テスト時の依存性注入のためにDIのライブラリは導入していませんが、必要な箇所ではinitializerで注入しています。

CI/CD

CI/CDの実行環境としてはBitriseとGitHub Actionsを使っています。 Macでの実行が必要なケースはBitriseを使い、それ以外はGitHub Actionsを使うといった使い分けをしています。

テストの実行、AppDistributionでのアプリの配布、テスト端末の登録、App Storeへのアプリのアップロード、リリースノートの生成といったことを自動化しています。

今年度やった技術的改善

ママリの開発業務をやるだけでなく、技術的な改善にも一定の時間を使うようにしています。今年度は主に以下のようなことをやりました。

Objective-Cのコードの撲滅
Swift Concurrency導入
脱Rosetta2
モジュール分割

技術的な改善の今後

今注力している技術的な改善はAPIKitの置き換えとAPI通信周りをRxSwift/CombineからSwift Concurrencyへの置き換えです。

その後やりたいこととしては、Swift Package Managerの導入や画面の一部をSwiftUIへのリプレース、起動周りのコードの改善などがあります。

最後に

コネヒトではママリの機能開発をしながらも技術的な改善を進める時間も一定確保しこのような改善を進めています。

コネヒトでの開発に興味を持っていただいた方はカジュアルにお話しましょう〜
TwitterのDMなどでも大丈夫ですので@yanamura_までお気軽にどうぞ
日本中の家族をITの力で笑顔にしたい、iOSエンジニア募集！ - コネヒト株式会社のモバイルエンジニアの採用 - Wantedly

2023-03-22

コネヒトはPHPerKaigi 2023にシルバースポンサーとして協賛します！

こんにちは！高谷です。今回は弊社が協賛するPHPに関するイベントを紹介します。

PHPerKaigi 2023に協賛いたします

コネヒトではメインプロダクトである「ママリ」を始めとして開発のメイン言語としてPHPを活用しており、フレームワークとしてはCakePHPを採用しています（その他、技術スタックを知りたい場合はこちらをご覧ください）

その縁もあり、この度 PHPerKaigi 2023 にシルバースポンサーとして協賛させていただくこととなりました！

イベント概要

日時 2023年3月23日（木）〜3月25日（土）
場所練馬区立区民・産業プラザ Coconeriホールおよびニコニコ生放送
主催 PHPerKaigi 2023 実行委員会
公式HP https://phperkaigi.jp/2023/
タイムテーブル https://fortee.jp/phperkaigi-2023/timetable

公式サイトからの引用になりますが、PHPerKaigiは

（ペチパーカイギ）は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。今年の開催はオフライン会場を軸としたオフライン・オンラインハイブリッド開催です。みなさんのご都合に合う参加方法をお選び頂けます。

となっており、いろんな方が楽しめる間口の広いPHPのイベントになっていそうです！今回ははじめてのハイブリッド開催なので、都合がつく方は両方で参加して楽しむこともできそうですね！

発表内容やタイムスケジュールを知りたい方はこちらをご覧ください！

タイムテーブル | PHPerKaigi 2023 #phperkaigi - fortee.jp

また、最新情報はTwitterで告知されるので PHPerKaigi 公式Twitterも要チェックです！

@phperkaigi

ブースも出します！

今年はコネヒトは企業ブースも出します！企画としては

1. あなたは何問正解できる!? ママリドリル

2. システム開発・運用に関するアンケート

を予定しております！ママリドリルやアンケートにお答えいただくとノベルティのチロルチョコがもらえます！可愛いチロルチョコになっているので、ぜひぜひご参加ください🙌

場所は会場内の研修室2で開催しております。

チケット購入

こちらからチケット購入できますのでよければぜひ！

www.eventbrite.com

最後に

ここまで読んでくださった皆様、ありがとうございました。そして、 PHPerチャレンジ中の皆様、お目当てのPHPerトークンはこちらです！

#connehito-techvision

それでは！

コネヒトではPHPerを積極採用中です！ご興味がある方は気軽にご連絡ください！

www.wantedly.com

2023-03-17

ママリ抽選会の裏側〜CakePHPで排他処理を使って実装してみた〜

こんにちは。ママリアプリ開発チームでエンジニアをしております高橋です。

今日は3月1日よりリリースされているママリ抽選会の実装についてお話ししていきます。

ママリ抽選会とは

ママリポイントを使用して参加できる抽選会のことです。

ママリポイントとはアプリ内で回答をしたり、ベストアンサーをもらったりすると付与されるポイントのことです。ただ現状でポイントを使用する用途があまりなく、ユーザーからのたくさんのお声とコネヒトとしてポイントを活用してユーザーに感謝の気持ちを伝えたいという背景から今回の「ママリ抽選会」プロジェクトがスタートしました。

テーブル設計

まずは簡単にテーブル設計を説明します。

以下は今回新規で作成した抽選会に関わるデータベースのER図です。

前提として開催期間に対して賞品それぞれに最大在庫があります。

在庫管理をするだけなら履歴テーブルは必要なく商品テーブルの最大在庫数を減らしていくという方法もあります。

ですが以下の懸念点を考えて最大在庫は固定でデータベースに保存するようにしました。

本来の最大在庫がわからなくなる
抽選会の参加履歴画面などが仕様が出てきた時に対応できなくなる

テーブル設計についてはそこまで複雑なことはないので本題の内部の実装についてお話しして行きます。

排他処理

排他処理とは簡単に説明すると「ダブルブッキングしないように制御すること」です。

前提として履歴を登録する前に次の抽選処理が始めると残在庫に誤差が生まれてしまうので順番に抽選する必要があります。そこで排他処理を利用して正しく処理できるようにしました。

今回はテーブル全体ではなく行に対してロックをかけて実現しました。

SQLでは排他処理はこのように書きます。idが1のデータのみ行ロックされています。

select *
from table_name
where id = 1
for update; // 行ロック

CakePHPでは以下のように書くことができます。念の為キャッシュ削除をすると安心です。

$table->find()
    ->modifier('SQL_NO_CACHE')
    ->epilog('FOR UPDATE')
    ->first(); // 行ロック

実装の流れは以下のようになっています。

$user = $this->ユーザーテーブル->get($id);
try {
    $connection->begin();　// トランザクション開始
    $lottery = $this->抽選会テーブル->find('active')
                　　　　->contain(['賞品テーブル'])
                　　　　->modifier('SQL_NO_CACHE')
                　　　　->epilog('FOR UPDATE')　// 行ロック
                　　　　　->first();
    // 参加資格があるかバリデーションをする
    // 抽選をする
    $connection->commit(); // トランザクション終了
} catch (Exception $e) {
    $connection->rollback();
    throw new InternalErrorException($e->getMessage());
}

よくある排他処理は複数のユーザーが同じデータを更新できないように制御していくイメージですが、今回に関しては抽選処理自体を止めたいので1番最初の抽選会テーブルのデータを取得するところでを制御する必要があります。

トランザクションを開始した後にselect文にfor updateを指定すると行ロックが発生し、この間は順番待ち状態になります。

トランザクション終了と共に解放され順番待ちしていた処理が開始する仕組みです。

これでどんなにリクエストが集中しても安全に順番に処理できます。

最後に

私は入社後大きな新機能実装は初めてだったので、テーブル設計、API設計、API実装、テストコード、レビューを一貫してやることができてとてもいい学びになりました。

設計をしていく上で難しいのが変更のしやすさだったり、どれだけ先を見通すかはすごく悩むポイントでした。

またチーム開発をしていく上で実装に入る前にモデリングだったり、設計の認識を合わせるということが大切だなと思いました。

色々大変なことはありましたが、新機能をリリースできたことはとても嬉しく思います。自分の中ではかなり大きな経験だったので次に活かしていきたいです！

【秘話】ママリ抽選会のリリース🎉までにデザイナーがやってきたこと↓

note.com

コネヒトでは一緒に働く仲間を募集しています！そして興味持っていただけた方は気軽にご連絡ください！ https://www.wantedly.com/companies/connehito/projects

2023-03-01

カオナビさんと合同LT勉強会を開催しました！

勉強会

こんにちは。2017年11月にAndroidエンジニアとしてjoinした@katsutomuです。

2023/2/16に株式会社カオナビの皆様と、オフラインの合同LT勉強会を開催しました！

経緯

昨年、コネヒト主催の勉強会に遊びにきてくれた、カオナビの富所さんに「所属してるエンジニアに刺激のあるイベントをやりたい」とお声がけして開催に至りました。

登壇をして、その場でFBや反応をもらえること
改まった場ではわからない、社外のリアルな声を聞くこと

この２つを刺激としてインプットし、成長につなげる場を作ることを目指し、まずはクローズドに交流&LT会を実施することになりました。*1

イベントの内容&趣旨

何度かカオナビさんと打ち合わせをさせていただき、以下の内容となりました。

全員自己紹介タイム
懇親会
LT大会

当日の進行はカオナビさんにお任せして、弊社としては非常に助かりました。ありがとうございます！

会場

今回は、カオナビさんのオフィスに遊びに行かせてもらいました。東京タワーが見える素敵なイベントスペースで、心地よく交流とLTの時間を過ごせました！

交流会

エンジニア業務のお話だけでなく、採用の取り組みであったり、組織カルチャーの話など、社内のコミュニティだけでは得られない、貴重な話ができました。

LT枠

当日の飛び入りも含め、合計8名の発表が行われ、大いに盛り上がりました。

発表内容も、エンジニアリングな内容や、プロジェクト管理のツールの話や、インディー開発など多岐に渡り、どの発表からも刺激をもらいました。

実施後のアンケート

実施後に、参加した弊社メンバーにアンケートを実施しました。結果として狙っていた、登壇でその場でFBや反応をもらう、 改まった場では得られない社外のリアルな声を聞くという点は、叶えられたかと思っています

アンケート結果

今回のイベントに期待してたこと（抜粋）

他社のエンジニアと接点を持つ
社外のエンジニアとの交流。社外LTの雰囲気が把握できる。
自分でLTを発表すること
社外にいるエンジニアの人とざっくばらんに技術的な話を楽しくしたい

定量評価

具体的なお声（抜粋）

時間があれば飛び込みでもLTできる雰囲気がいいなと思いました。
色々なテーマのLTがあって面白かった反面、テーマを絞ったLTもいいなーと思いました
久々にリアルでエンジニアと話せたし、境遇似た人との会話は自分も楽しく周りも楽しんでいたように見えたのでよかった
クローズドな交流会だと色々とぶっちゃけた話ができるのがとても良かったです。

まとめ

クローズドなイベント開催がひさびさなこともあり、盛り上がるか心配していましたが、大盛況で終えることができました。関わってくれたみなさんのお陰です。本当にありがとうございます！

オンライン勉強会が主流になり失われていた、リアルな交流ができたと思っています。特にエンジニアになって2~3年の若手メンバーだと、経験する機会が少ない文化だと思いますが、得られることも多いので、今後も継続して開催していきたいと思います。興味のある方は、ぜひお声がけください！

*1:コネヒトにはインプットとアウトプットを支援する制度があります：https://tech-vision.connehito.com/program/smile.html

2023-02-02

【iOS】GoogleSignIn v7.0.0へのアップデート対応方法

iOS

こんにちは！2023年1月にiOSエンジニアとしてjoinしました、yoshitakaです！

今後iOS関連の内容で定期的に発信していきたいと思いますので、よろしくお願いいたします！

ママリのアプリではログイン連携でGoogleSignInを使っておりますが、先日GoogleSignInのメジャーアップデート対応を行ったので、内容を簡単にまとめたいと思います。

Google Sign-Inとは

Google Sign-In とは、Googleが提供している認証系ツールで、スマホアプリやWebアプリの認証をGoogleアカウントでできるようにするものです。

developers.google.com

Google Sign-Inを使ってやっていること

ママリユーザーが自分のGoogleアカウントを連携させることで、ママリ内でGoogleアカウントでのログインを可能にしています。

内部の処理としてはユーザーがGoogleログインに成功後その認証情報をサーバで確認、連携済みの場合にママリへのログインを許可しています。

アップデートで変わること

v7.0.0リリースノートより以下3点の変更がされました

すべての構成を Info.plist で指定できるように
Swift Concurrency のサポート
API の改善

アップデートで対応したこと

clientIDを Info.plist で指定
API の改善による修正

の2点を対応しました。

GoogleログインからidTokenをサーバへ送る際の実装部分(対応前)はこのようになっておりました。

let config = GIDConfiguration(clientID: clientID)
GIDSignIn.sharedInstance.signIn(with: config, presenting: self) {
    [weak self] user, error in
    if error == nil, let idToken = user?.authentication.idToken {
        self?.loginViewModel.loginWithGoogleId(idToken: idToken)
    }
}

Info.plist の修正

まずは、clientIDの指定をInfo.plistに移します。

ドキュメントを参考にGIDClientIDの値を追加しました。

ソースコードを修正する場合はこちらを追加

<key>GIDClientID</key>
<string>${GOOGLE_SIGNIN_ID}</string>

今回はRelease,Develop, Localで値を変えたいため

Build SettingsのAdd User-Defined Settingより環境ごとに値を指定して使います

ログイン部分の修正

次にログインの実装部分を修正します。

Info.plistに追加したことでGIDSignIn.sharedInstance.signInでclientIDを渡す必要がなくなりました。

また、ログインが成功したかどうかを表す新しい GIDSignInResult が追加されました。

以前user?.authentication.idTokenから取得していたidTokenは

signInResult?.user.idToken?.tokenStringとすることで同じ値が取得できました。

GIDSignIn.sharedInstance.signIn(withPresenting: self) { 
    [weak self] signInResult, error in
    if error == nil, let idToken = signInResult?.user.idToken?.tokenString {
        self?.loginViewModel.loginWithGoogleId(idToken: idToken)
    }
}

まとめ

APIの改善により他にも変わっている部分がいくつかありました。

この記事では修正が必要になった部分のみ記載しておりますが、公式ドキュメントに詳しくありましたので対応される際は確認してみてください！

developers.google.com