9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

個人開発アプリのシステム構成の話と今後の計画

Last updated at Posted at 2019-12-19

Ubiregi Advent Calendar 2019 19日目の記事になります。

今回は個人で開発中のアプリのシステム構成の紹介と、そのシステム構成をどう変更していくかという計画の話をします。

アプリ概要

現在iOS向けに「ゴミアプリ」というそのままの名前でゴミ収集日のカレンダーアプリを出しています。

現在のシステム構成

概要

主にはFirebaseのFirestoreに各自治体のカレンダーデータを格納しておき、アプリ側でそのデータを取ってきてカレンダーとして表示しています。
自治体のカレンダー以外に自分で収集パターン(例:毎週火曜日は燃えるゴミ、など)を登録して、そのパターンを組み合わせて独自の収集日カレンダーを作る機能も提供しています。こちらはローカルのrealmにデータを保存し、取り出して加工しています。
ただこの構成でいくつか「問題点」があって、将来的にiOSローカルでやっているところをすべてFirebaseに移行したいなと考えています。

Untitled.png

現在アプリが抱える問題点

構成図を見ると左下の通知部分が未実装です。
未実装の理由としてはLocalNotificationで通知機能(「今日は資源ごみです」みたいな通知)を実装しようとしたのですが、LocalNotificationでは機能要件を満たさないことがあとから分かって一旦開発を止めたのです。

機能要件を満たすため、RemoteNotificationにしたいのですが、そうなるとローカルにある「収集パターン」のデータと、ユーザーの設定値(どの自治体のデータを取ってくるのかという設定値)もリモートに置く必要がでてきます。

将来的に目指したいシステム構成

計画

というわけでいろいろとリモートに上げていかなければならないので以下のような構成を計画しています。

未来予想図.png

変わったところ

大きなところとしては、Cloud Functionsです。
Cloud Functionsに通知送信のためのバッチ処理をやってもらおうかなと考えています。更に収集パターンからカレンダーデータを作成する処理もまかせています。将来的なAndroind対応を考えるとそれぞれにロジックをもたなくて済みますからね。

あとはユーザー設定も通知のときに必要になるので、Firestoreに移行します。

最後に

計画についていろいろ考えてきました。そこから具体的にやらないといけないことをリストにするとこんな感じでしょうか。

  • セキュリティルール変更・テスト
  • ゴミ収集パターンからカレンダーデータ作成する処理の設計・実装・テスト
  • ゴミ収集パターンのテーブル追加
  • 通知の設計、通知登録処理の設計と実装
  • 通知設定のテーブル追加
  • バッチ処理設計・実装
  • ユーザー設定のカラム追加

超大変。一個も手をつけていません。

なかなか大変なので一旦これは横においといて、iOS13周りで対応しないといけないところがあるので、そちらの修正からやって行こうと思います。

9
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?