iOSはまだ書き始めて半年もたたないひよっこですが、これくらいのプレッシャーでもないと勉強しないだろうということで今回エントリーしました。いうライブショッピングのアプリを運営しています。作り始めた時はiOS初学だった僕ですが、最高のメンターさんと今をときめくFirebaseの力のおかげでこのアプリを2ヶ月で仕上げることができました。このケースに関する記事は僕の知る限りこの世にあまり存在しないので、Firebaseへの恩返しの意味もこめて、この認証のiOS側の実装の方法とそこで苦労したことについて書こうと思います(Firebaseのcalendarでやれ)。Service)の1つです。2014年にGoogleに買収されて一躍有名になりました。詳細は以下に素晴らしいQiitaの記事を添付して割愛させていただきます。本格的にサーバーレスで生きていけるなと思ってしまうほど素敵なサービスです(唯一欠点を挙げるとすれば日本語の公式リファレンスが古いのでサンプルコードがたまにアレです)。ライブラリが用意されています。プロバイダ(Google、Facebook、Twitter)などを使用した認証を行うことができます。いろんなログイン方法が簡単に実装できるだけではなく、それらでログインしたUserをFirebaseのsdkを通すだけで一元に管理できるのでとても素敵です。これは他のFirebaseのサービスへのアクセスに使用するというのがスタンダードな使い方だと思うのですが、公式のsdkを使ってあれこれするだけで自サービスのサーバーサイドの認証にも使えます。Token)をリクエストにのせて送信サーバー側でそれを検証することで認証という感じです。世にたくさん記事があるので割愛したいと思います。1さえ超えてしまえばclientでやらなければいけないことはとても単純です。idTokenはとても簡単に取得することができます。}}そしてリクエストのheaderにtokenを配置します。使わせていただいているので、以下のような感じになります。渡すコールバックの中でhogehogeしたり、RxつかったりでRequestにidTokenをつけることができれば、あとは送るだけです。あとはこのidTokenを検証した後decodeしてuuidなどの情報を得ます。実装するだけならばこれだけなのですが、PinQulでは一点めんどくさいところがあったので最後にそれに触れて終わりたいと思います。ログインが必要な機能とそうでない機能がある。これは少しめんどくさかったです。世の中のライブストリーミングのサービスのほとんどがライブを見るだけであればログインをスキップできるようになっています。PinQulも御多分に洩れずそういった実装にしているので認証(idToken)が必要な場合とそうでない場合があります。リクエストを飛ばす時にそのリクエストに認証が必要かを判断する必要があります。その処理に特化したprotocolを用意して、各Requestにそれを継承させ、認証がいるかいらないかの判断をジェネリクスを使って行わせることにしました。extensionを貼って実装しています。}}これでiOS側の実装は完璧です!あとはサーバー側でこれを検証して、正常に認証できたらdecodeしてデータを取り出しましょう。公式のリファレンスに詳細に書いてあるので問題ないと思います。FirebaseおわりにXcodeも今ではとても使いやすくなっていますし、Firebaseなんていうとても素敵なサービスが現れてアプリの開発のハードルがとても下がり、僕のような初学者でもゴリゴリアプリが作れるようになりました。この記事で利益を被るのは本当にごくわずかな人だと思いますが、最後まで拙い文章をよんでいただきありがとうございます。本当に力不足なのでマサカリ大歓迎です。お願いします!PinQulは以下のURLからインストールできます。サーバーの認証に使い自サービスのUserと紐づけた話(iOS編)Tweetもっと読むコメントを書く2017-08-31多人数でのiOS開発におけるStoryboardとの向き合い方(1画面1Storyboard)※僕が試行錯誤したストーリーが前半を占めてるので興味がなければ読み飛ばしてくださいStoryboardと付き合うStoryboardやAutoLayoutの出現によって、iOSアプリケーション開発に置けるViewの実装のハードルは確実に低くなりました。弊社のプロダクトでも惜しみなくStoryboardを使用しています。多くの方がStoryboardとの向き合い方について頭を悩まされてきたと思います。例として以下のCookPadさんの記事では1つのStoryboardにViewControllerを複数配置して、Segueで画面遷移を実装(しかしViewは再利用したいのでxibファイルの形式で切り分ける)という手法が取られています。techlife.cookpad.com一瞬でこれだ!と思い、採用させていただきました。似たようなUIを何度も再利用していくアプリとの親和性は相当高い思います。この設計で一生開発していくんだと思っていました。最初は、、、Storyboardの闇に触れる正直1人で開発を進めていくのであれば、1Storyboardに全て詰め込んでしまうのが一番シンプルで楽かなと思います。複数人開発になった瞬間にそういうわけにはいきません。恐るべきことに異なるbranchで同じStoryboardを触るとほぼ確実にconflictが起きます。このconflictが厄介で、conflictが発生した瞬間そのファイルはxcodeで開くことができなくなり、コードを見て愚直に1つ1つ問題を解消するしかなくなります。それも実力不足の僕の場合高確率で失敗するので、泣く泣く片方の変更を捨てることもしばしばです。PRをだすたびに赤く染まるGithubの画面。「いっそのことStoryboardなんて使わなければよかった」、そんな考えが頭をよぎりました。1画面1Storyboardという選択そんなある日、某グルメサービスのiOSエンジニアさんとお話する機会があり、この悩みをぶつけたところ、「弊社は1画面につき1Storyboardでやってますね」という答えが帰って来ました。確かに画面ごとにファイルを分けて画面ごとにタスクを分担すれば、まずconflictは起こりません。最初は「何を言ってるんだ、Segueを殺して何が楽しい」と憤ってた僕ですが、これが最高でした。以下で詳しく説明します。別のStoryboardのViewControllerに移動するのは実は大して難しくありません。presentするみたいに3行でいけます。基本的には1ViewControllerにつき1Storyboardを用意してあげる各Storyboardに適切な名前をつける上記のコードで画面遷移!これで大丈夫でしょう。Storyboard経由でViewControllerを取得してる感が鬱陶しいので、弊社ではもう少し精錬して使用しています。以下の3STEPです。以下のようなprotocolを定義します。これを各ViewControllerに継承させるstoryboardNameをそれぞれで定義しましょう。presentするかなりシュッとしたと思います!ViewControllerベースで次の画面取得してる感が好きです。終わりにこのやり方はあくまで一例であって、他にも色々な設計があり、それぞれが長所・短所を持っていると思います。その開発の環境に応じた最適なものを採用するのが一番ですが、多人数開発をするとき、この手法をチラッと思い出していただけると本望です。_k0mach1月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。