Haruka

Engineer

プロジェクトの詳細

アプリStayONの通話機能主体からスレッド機能へと変換する開発。

使用技術

  • Dynamic Links
  • Firebase Cloud Messaging
  • Firestore
  • Cloud Function
  • SwiftUI

参加期間

  • 2023年2月〜2023年5月

開発規模

  • 4人 開発は1人

プロジェクトでの課題

通話アプリの検証結果として、コミュニケーションをするにあたって予想以上に通話そのものがハードルになっていた。通話だとサービスが始まってすぐの少ない期間に、他のユーザーが居なくて通話出来なかったり、通話をしても話せる話題が出にくいなど同期的なコミュニケーションを快適に取る事が出来てなかった。 そのため、コミュニケーションの形をテキストにして非同期でも会話可能な状態へと変える必要があった。

主な取り組み

  • 不要なコードの削除
  • トピックで話せるスレッド機能への移行
  • カテゴリーの作成と自動割り振り
  • Twitter、NewsAPIから話題の取得とスレッド自動作成
  • スレッドの新規作成とシェア機能のディープリンク対応
  • スレッドの制限時間・アーカイブ機能
  • お知らせ機能の実装

【不要なコードの削除】

通話からテキストでのチャットを行う形に変更するため、画面共有に使っていたコードや使わなくなった通話機能などのコードを全て削除することから始めました。Swiftだと定義されてない関数や変数があるとコンパイルエラーになるため、ViewModelなど大元を全て削除してエラーが出た部分を全て削除していきました。

【通話からスレッド機能へ】

スレッド機能の実現にあたって、Twitter、NewsAPIの使い方から学び話題の取得とスレッド自動作成、スレッドの新規作成機能を追加しました。また、シェア機能のディープリンク対応、スレッドの制限時間・アーカイブ機能などをアプリに導入しました。

アプリ内で使用するカテゴリーはGoogleのNatural Language APIの分類リストから使う物をピックアップして使いました。採用理由としては一定リクエスト無料な事、Twitterのツイートからスレッドを作成する時にカテゴリ分類を自動で選択できると判断したからです。その際、どれがアプリにあると絞り込みやすいかなどを相談しながら決めていきました。 実装では、文章をAPIに渡し返却されるカテゴリ候補から一番有力なカテゴリの大カテゴリだけを抽出するロジックを書き、Firestoreからarray-containsでAPIカテゴリ名を使って取得できるようにしました。そして、スレッド作成時にIDを紐づけをすることで、記事を作成する際にカテゴリの割り振りを自動で行えるようにしました。 苦労した点としては、EmulatorだとNatural Language APIがPermissionエラーで実行できない事でした。Emulator内部からAPIキーを使う際、Twitterのアクセスなどは行えていましたが、NaturalLanguageAPIだけ権限エラーで実行できていませんでした。ローカルで使うためには自分が誰なのかを指定する必要があると気づき、サービスアカウントのキーを作成して実行時に使うことでAPIを使うことができました。

【News, TwitterAPIでの自動スレッド作成機能】

NewsAPIとTwitter APIを使って記事やトレンドツイートを取得しスレッドを作成する処理とPubsubを使ってその処理を一定間隔で自動発火するようにしました。スレッドには話題となるトピックが必要で、初期の時点ではユーザー自身が作成することは少ないため話題がいくつかある状態にして会話に移らせることが狙いでした。そのため、トピックに出来そうなAPIを探しました。APIを使って自動で作成できるようにしておくことで、運用でスレッドを作る手間を省ける意図もあったため何かしらのAPIを使った実装が必要とチーム内で判断しました。

NewsAPIは非公式のライブラリを使い、処理部分と記事作成部分を分けて処理を作成しました。そうすることにより、今後APIを使うときに取得部分をそのまま使いまわせられるようになると考えました。そして引数に記事数を指定し記事カテゴリー毎に3件の記事を取得してその結果から記事を作成する関数を実装しました。NewsAPIで使うカテゴリもNatural Language APIと同様にFirestoreのフィールドに保存しておいてそこから検索できるようにしてカテゴリーのIDの紐づけを行いました。

TwitterAPIでも非公式ライブラリを使用してトレンドからツイートを取得する処理を書いて、ツイートの本文を合算してNatural Language APIでカテゴリを分類した上でスレッドを作成しました。公式ライブラリだとv2エンドポイントの型のみ記載されていてv1.1の型がなかったため非公式のライブラリを使用しました。まず、Discordに送信する形でTwitterのsdkを試しながらトレンドの取得と取得したトレンドからツイートを取得する処理を実装しました。DiscordのライブラリもJavaScriptで書けるため移行がしやすく簡単に試すことができました。その時作ったコード

【スレッド作成】

新規作成画面では、スレッドの画像選択としてiOS16から使導入できるPhotosPickerを使用しできるようにしました。 登録した画像はFirestoreのStorageに保存していたのですが、帯域の料金が思った以上に増えていたためKingfisherを入れてキャッシュしたものを取得・表示するようにして帯域を節約できるようにしました。 次に、Firebaseで作成したDynamicLinkからアプリをインストールしていたら該当のスレッドに遷移できるようにディープリンク対応をしました。 遷移処理はiOS16で使いやすくなったNavigationStackを使いアプリ内の共通の遷移を一元化できるよう実装しました。その時作成した記事

【アーカイブ機能】

自動作成されたスレッドやユーザーのスレッドが残り続けると新しいスレッドを探しづらいのと、スレッドが消えるのを阻止するためコメントを定期的に行わせるようにするため、スレッドの時間制限機能とアーカイブ機能を実装しました。 これにより、ユーザーが部屋を作りたがったり、その部屋を消さないようにコメントをしたりとより多くの時間を費やしてくれるようになりました。

【お知らせ機能】

お知らせ画面ではスレッドでコメントが来た時や返信が来た時の通知を表示できる画面と、お知らせ画面の実装に合わせてバックエンドから端末にプッシュ通知を送る処理を変更しました。 アプリ、バックエンド両側で処理を作成していましたが非推奨なやり方だったので、通知の処理をバックエンドでまとめられるように変更しました。 実装後はCloudFunctionのonCallメソッドを呼び出す構造体を定義して、通知の具体的な処理はバックエンドで行えるようにしたことでアプリ側での処理が簡潔にできました。

【感じたこと】

スレッドでのやり取りに変え、Twitter運用などマーケティングをする人が頑張ってくれたおかげで一時はアプリランキングで175位とランキングに載る事が出来ました。 APIを使う事で簡単にアプリ機能の幅を持たせる事ができ、よりリッチな機能を開発できたため楽しかったです。また、その実現にGithub Copilotを個人的に導入したことで開発がやりやすくなりました。 iOS16では使いやすいメソッドが増えた時も、何か使えそうなのがないか調べることでディープリンクの実装が簡単に行えるようになったりとキャッチアップしていた事が開発に活かすことができたと考えています。