1. 概要
仲間内でAzure Communication Services のiOS 用のグループ通話のヒーロー サンプルを動かしてみたいという話があり、Azureをさっぱり知らないのでまずはWeb版から動かしてみる。
2022/09/04時点
2. 準備
2.1 参考情報
ここを参考として紹介されたが、Azureに詳しい人なのか、記事の時期のせいなのか何かしらの違いを感じた。
【爆速】Azure Communication Services を早速試してみた!
2.2. アカウント作成
Microsoftアカウント、Azureアカウントは作成できているものとする。Microsoftアカウントを既にもっていたので、メールアドレスとかを入れるだけで済んでしまい、一からの手順で困る点は不明。
Azureにログインと確認
Azureにログインする
https://portal.azure.com/#home
こんな画面のはず。新規アカウントだと何もない。
1, 2年前のブログ等だと表示が英語のものがある。ブラウザで翻訳していないが。日本語なので情報源との一致がとりにくい。
3. リソースの確保
自分が立ち上げたいサービスのためのリソースを確保しなければならない。今回使うのは、「Azure Communication Services」となる。
検索窓に「Azure Communication Services」で検索して出てくる Communication Services
での「リソースの作成」を行う。
他の情報源では、検索してもうまく見つからないケースがあったようだ。あと、通信サービスと翻訳されて表示されていたりもした。(ブラウザの翻訳機能によるものではない)
リソースグループをどうすべきかよく分からないが、とりあえず新規作成して名前を付けた。
そうすると、「リソース グループの位置情報」が出てきたので、「Japan East」とした。
米国に~と注意みたいのが出ているが、今回はとりあえずの動作が目的なのでほっておく。
作ったばかりのアカウントなので、リソースの作成の開始でエラーは出ないと思う。
デプロイは多分1,2分で終わる。デプロイの完了の後に「リソースに移動」をクリックして、リソースに移動する。
設定->キーに移動する。
「エンドポイント」、主キーの「キー」と「接続文字列」をメモしておく。
※資料によっては、KeyとConnection stringになっている。そのままなのだが、検索すると引っかからない。
4. サンプルコードを試してみる。
ここの公式サンプルを使う。
iOSですぐに試すと何が起きるか予想できないので、まずは「Web版」
4.1. Web版
4.1.1 デプロイする
Webを選んでいる状態(デフォルト)で、「Deploy to Azure」をクリックする
「リソース グループ」は新規作成で作った名前。
「App Name」は自分でつけるサービス名。とりあえずならなんでもよいはず。
画面下側の「確認と作成」に進み、検証が終わったら「作成」する。
こちらは最初のデプロイより長いがせいぜい5分までで終わる。
4.1.2 使ってみる。
デプロイ完了後、「リソースに移動」してみる。が、動いているサービスがどれか分からない。。。
色々探してみて、リソースグループの「App Name」でつけたリソースに移動するとサービスのURLらしき
情報を見つけたので、クリックしてみた。
4.2 iOS版
使用機器: MacBook Air (M1, 2020), macOS Monterey 12.5.1
Xcode 13.3
以下のソースコードを取得。
指示通り、pod installをソースのトップディレクトリで行ってからAzureCalling.xcworkspaceをXcodeで開き、ビルドしたところ、エラーが出た。
ソースコードの変更が必要だとしても現段階ではやりたくない。あくまでiPhoneなどで動作確認をしたいだけである。
どうやらシミュレータを選択しているのが良くなかった。このビルド環境ではソースコードからシミュレータ用をビルドできないようだ。デバイスを「Any iOS Device (arm64)」に変更したところ、ビルドエラーがなくなった。
AzureCallingのSigning&CapabilitiesにあるBundle Identifierの値が原因でエラーとなることがある。ネット上の情報に従い、日付などを付けると回避できるが、今回は後述の箇所でサーバー側エラー要因となったので注意したい。
例) com.azure.samples.communication.calling -> com.azure.samples.communication.calling0924
4.2.1. アプリがハングアップする
iOSアプリをiPhoneで動作させるまではいけるが、その後のCall操作でアプリがハングアップした。
AzureCalling/External/Calling/TokenService.swift内の「JSON Parsing of the token response failed.~」の箇所である。設定値として記載されているcommunicationTokenFetchUrlに使えそうな値を色々いれてみたが、結果は変わらずエラーであった。つまりよく分からない。
そこで、「(Optional) Securing an authentication endpoint」の項目、日本語約だと「(省略可) 認証エンドポイントのセキュリティを確保する」となっている項目を試すことにした。とりあえずテストする分には不要だろうと判断していた作業である。
4.2.1.1. アプリを Azure Active Directory に登録する (iOS または macOS プラットフォームの設定を使用)
「アプリケーションの登録」の登録のところだけ行った。
バンドルIDは、上述の通り「com.azure.samples.communication.calling」とする。MacOSでビルドの際の変更していてもサンプルコードの最初のままとする。
4.2.1.2. Azure AD ログインを使用するように App Service または Azure Functions アプリを構成する
以下の公式の手順にしたがって設定する。
なぜ2つ出来てしまったのかよく分からないが、2つ出来た。接続に使用したのは上の方。
シングルテナントだとエラーが出てしまったので、ここは後からマルチテナントに変更した。
「App Service アプリで Azure Active Directory を有効にする」の結果
4.2.1.3. ユーザー追加
実験用のユーザーを追加する。これはぱっと見で公式資料に書いてないような?
ホーム>Azure Active Directoryに移動し、左側のユーザーから管理画面に入る。
結果は以下のようになるはず。尚、パスワード設定をしたが、最初の使用(サインイン)時に変更を求められた。関係する設定があるのかは確かめていない。
4.2.1.3. AppSettings.xcconfig
動作したときのAppSettings.xcconfig は以下になった。URLにはMacOSでビルドする際のバンドルIDの日付が入った状態。いずれの値もアプリ(この記事内だとcomm-sample1)の概要から確認できる値。
communicationTokenFetchUrlは未だによく分からない。
communicationTokenFetchUrl = msauthcom.azure.samples.communication.calling0924
aadClientId = e9d3bd6f-8b18-4ee8-9406-d~略~
aadTenantId = 6dba2d58-595d-474d-9c14-e~略~
リビルドして問題なければ動作するはず。
communicationTokenFetchUrlについて分かったので別記事参照(2024/05/28追記)
5. 予定
- iOS版を動かす。(2022/09/11 ビルドまで)
- Azureについてもうちょっと勉強して初心者が躓きやすい点について補足する。