Ubiregi Advent Calendar 2019 19日目の記事になります。
今回は個人で開発中のアプリのシステム構成の紹介と、そのシステム構成をどう変更していくかという計画の話をします。
アプリ概要
現在iOS向けに「ゴミアプリ」というそのままの名前でゴミ収集日のカレンダーアプリを出しています。
こんなアプリです。 pic.twitter.com/JgE2yEYVto
— 「ゴミアプリ」開発者 (@gomi_tech) January 19, 2019
現在のシステム構成
概要
主にはFirebaseのFirestoreに各自治体のカレンダーデータを格納しておき、アプリ側でそのデータを取ってきてカレンダーとして表示しています。
自治体のカレンダー以外に自分で収集パターン（例：毎週火曜日は燃えるゴミ、など）を登録して、そのパターンを組み合わせて独自の収集日カレンダーを作る機能も提供しています。こちらはローカルのrealmにデータを保存し、取り出して加工しています。
ただこの構成でいくつか「問題点」があって、将来的にiOSローカルでやっているところをすべてFirebaseに移行したいなと考えています。
現在アプリが抱える問題点
構成図を見ると左下の通知部分が未実装です。
未実装の理由としてはLocalNotificationで通知機能（「今日は資源ごみです」みたいな通知）を実装しようとしたのですが、LocalNotificationでは機能要件を満たさないことがあとから分かって一旦開発を止めたのです。
機能要件を満たすため、RemoteNotificationにしたいのですが、そうなるとローカルにある「収集パターン」のデータと、ユーザーの設定値（どの自治体のデータを取ってくるのかという設定値）もリモートに置く必要がでてきます。
将来的に目指したいシステム構成
計画
というわけでいろいろとリモートに上げていかなければならないので以下のような構成を計画しています。
変わったところ
大きなところとしては、Cloud Functionsです。
Cloud Functionsに通知送信のためのバッチ処理をやってもらおうかなと考えています。更に収集パターンからカレンダーデータを作成する処理もまかせています。将来的なAndroind対応を考えるとそれぞれにロジックをもたなくて済みますからね。
あとはユーザー設定も通知のときに必要になるので、Firestoreに移行します。
最後に
計画についていろいろ考えてきました。そこから具体的にやらないといけないことをリストにするとこんな感じでしょうか。
- セキュリティルール変更・テスト
- ゴミ収集パターンからカレンダーデータ作成する処理の設計・実装・テスト
- ゴミ収集パターンのテーブル追加
- 通知の設計、通知登録処理の設計と実装
- 通知設定のテーブル追加
- バッチ処理設計・実装
- ユーザー設定のカラム追加
超大変。一個も手をつけていません。
なかなか大変なので一旦これは横においといて、iOS13周りで対応しないといけないところがあるので、そちらの修正からやって行こうと思います。