見出し画像

オモカゲ開発17~18日目:ログイン認証、ログ・エラーハンドリング、アイコンなど

顔がポイントカードになるアプリ、オモカゲを開発中のthere2です。

17~18日目にかけてはどのアプリにも不可欠ですが、あまり面白くない作業を進めていました。
今回ログイン認証、ログ・エラーハンドリングは最後にまとめて実装する方法を取りましたが、ずっといつかやらなきゃな、と心の負担になっていました。

今回の開発で自分の中でパターンができたので、次回からは最初から対応していく方が良いように思います。

やりたくないことを後回しにまとめてやるのはよくありませんね。

ログイン認証

ログイン認証はfirebase authを利用します。
匿名ログインですが、利用ユーザ毎に固有のuidを発行してくれて、同じユーザの利用をトラッキングする事が可能です。

このuidはAIのwebサービスでの認証で確認したり、アプリがクラッシュした時、ユーザからメールで問い合わせしてもらう時などに原因特定に利用する重要なキーとなります。

画像1

初回起動して初期設定が完了する時にuidを発行するようにしました。

ユーザがアプリのデータを削除してしまえば消えてしまってまた次の起動時に新しくuidが採番されるようになります。

もう一つ、Heroku上でPythonで実装しているAIのWebサービス上で、firebase authで発行したtokenを検証する処理が必要でした。
ここはいろいろなサービス、技術の組み合わせになっていてなかなか難しく苦労しました。無事に実現できてよかったです。

また、tokenの検証による処理時間への影響を心配していましたが、処理時間的には殆ど影響なさそうで良かったです。

ロギング

同じくFirebaseのアナリティクスを利用して最低限のロギングを行います。
アプリ起動時、画面の遷移時、そして売上登録時に操作ログをFirebaseに送信して見れるようにしました。

ログは単純に操作ログだけで、個人が特定できるような情報は送らないようにしています。

まだどういった情報がFirebaseコンソールで確認できるのかわかっていませんが、少なくともアプリがどれぐらい利用されていてどの画面が多く起動させているかは分析できそうです。

こういうのを個別に作らなくていいのは個人開発には非常にありがたいですね。

画像2

エラーハンドリング

一番面倒で気が進まないものですが、アプリが意図せずクラッシュした場合に原因が特定できるようにログを記録してクラウドサーバに溜めていく必要があります。

同じくFirebaseのCrashlyticsというサービスを活用しています。

いくつか試しにエラーを発生させてみました。
少しタイムラグがあるようですが、モバイル上で発生したエラーの内容を確認できる優れものです。

画像3

エラーをサーバに溜めこむ部分はCrashlyticsで時間かけずに対応できました。

一方で個々のエラーが発生した時に画面の動きが止まったり何も操作できなくなってしまわないように、それぞれエラーを発生させて動作確認して、という作業が大変で骨が折れました。

次回からは後でまとめて対応するのではなく、最初から一つ一つ対応していこうと心に誓いました。

スプラッシュスクリーンとアイコン

アプリのアイコンを作成し、またイメージ画像をスプラッシュスクリーンで表示できるようにしました。

この対応をするとグッと本格的に見えるのでうれしいですね。

アイコンはちょっと小さくてわかりにくいかもしれませんね。

画像4

スプラッシュスクリーンは我ながらいい感じでできました。

画像5

開発進捗サマリ

開発着手:2020年5月14日
作業日数:18日
作業した時間合計:120時間
ファーストリリースに向けた進捗:81%

今週は後は細かい気になる部分の修正とレスポンシブ対応をする予定です。
そしていよいよ来週から統合テストを実施します。

それが終われば後はWEBページとWEBマニュアルを用意してリリース。今月中にはリリースできる見込みが立ってきました。

画像6

作業していると使いやすくするためのいろいろなアイデアを思いついてしまうのですが、対応しているとキリがないのでなんとかあきらめて次に進むようにしています。

来週からはバグフィックス以外は対応しないように自分に言い聞かせないといけませんね。