Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

プッシュ通知対応全般のリバイス #135

Open
3 of 4 tasks
inafact opened this issue Nov 18, 2019 · 4 comments
Open
3 of 4 tasks

プッシュ通知対応全般のリバイス #135

inafact opened this issue Nov 18, 2019 · 4 comments
Assignees
Labels
enhancement New feature or request functional issue Extra attention is needed

Comments

@inafact
Copy link
Member

inafact commented Nov 18, 2019

  • サーバー側の送信データフォーマット策定
  • サーバー側の実装対応
  • アプリ側の通知時挙動実装(サウンド・バッジなど)
  • 通知タップ時の遷移対応
@inafact inafact added enhancement New feature or request functional issue Extra attention is needed labels Nov 18, 2019
@inafact
Copy link
Member Author

inafact commented Nov 18, 2019

@hiroyuki

本件、 #120#121#122#91 の内容をマージしたものとして再度作成し直します。
(諸々調査&テストに時間がかかっておりスケジュール当初の見立てより押しております..)

以前slack上でも触れたのですが、現在のプッシュ通知の実装が(特にサーバー側)、もともとあったもののをそのまま使っているだけだと思われるので、基本的にはやはり必要な機能に応じてfirebase側に送信するデータフォーマットを調整してもらう形になると思います。
こちらは別途slack上でクイストさんと詰められればと思います。

そのうえで、本アプリで扱うプッシュ通知の仕様について再度確認したいのですが、

  • 対象となるものはアプリ内の「メッセージ」のビューで扱うもの。グループメッセージ、個人間のメッセージ(トピック関連・ダイレクトメッセージ)、システムからの自動配信メッセージ
  • iOSバッジにおけるカウント = メッセージの未読件数?という認識であっているか
  • ノーティフィケーションの表示内容のフォーマット:タイトル、配信者名、本文
  • ノーティフィケーションをタップした際の挙動:(バックグラウンドの場合はアプリを起動した上で)該当のメッセージスレッドビューに遷移

というような内容で大丈夫でしょうか。

また、現状クライアントアプリ側でブロックするユーザーを管理していますが、プッシュ通知についてこれらブロックしたユーザーからのメッセージをハンドリングする必要がある場合、アプリがバックグラウンド時には

  • Androidについては公式な方法では振り分けなどの独自処理は対応できない
  • iOSではUser Notifications Frameworkの拡張機能を使う事で実現できそうだが、バックグラウンド時の処理におけるリソース制限の関係上、あくまで付加的なコンテンツの表示に使用される想定なので、「必ず行わなければならない」ような分岐処理を挟むのは望ましくない(ユーザー側の電源管理設定などの影響で実行されない場合がある)。

という点から、通知自体を表示させないためには、こちらに関しても基本的にはサーバー側で振り分けてもらうのが最もシンプルであるという認識です。

@hiroyuki
Copy link

対象となるものはアプリ内の「メッセージ」のビューで扱うもの。グループメッセージ、個人間のメッセージ(トピック関連・ダイレクトメッセージ)、システムからの自動配信メッセージ
iOSバッジにおけるカウント = メッセージの未読件数?という認識であっているか
ノーティフィケーションの表示内容のフォーマット:タイトル、配信者名、本文
ノーティフィケーションをタップした際の挙動:(バックグラウンドの場合はアプリを起動した上で)該当のメッセージスレッドビューに遷移

こちらにプラスして、着金もカウント+ノーティフィケーションさせたいです。

対象となるものはアプリ内の「メッセージ」のビューで扱うもの。グループメッセージ、個人間のメッセージ(トピック関連・ダイレクトメッセージ)、システムからの自動配信メッセージ
iOSバッジにおけるカウント = メッセージの未読件数?という認識であっているか
ノーティフィケーションの表示内容のフォーマット:タイトル、配信者名、本文
ノーティフィケーションをタップした際の挙動:(バックグラウンドの場合はアプリを起動した上で)該当のメッセージスレッドビューに遷移

これに関しては、致し方ないと思うので、ブロックしたユーザーからものに関してはとりあえず、考えないようにしましょう(例外として処理しない)。

@inafact
Copy link
Member Author

inafact commented Nov 18, 2019

@hiroyuki

こちらにプラスして、着金もカウント+ノーティフィケーションさせたいです。

基本送金時にシステムメッセージが配信されると思うので、それらがサーバー側で未読カウントの対象になっていることと、firebase側への送信処理が行われていればOKかなと思います。
合わせて確認ですかね。

これに関しては、致し方ないと思うので、ブロックしたユーザーからものに関してはとりあえず、考えないようにしましょう(例外として処理しない)。

これは通知自体は届いてしまってもOKで、その後のアプリを開いた際の挙動でハンドリング(「ブロックしているユーザーなので見れない」などのアラート表示を出すなり?)、というような認識で合っていますか?

@hiroyuki
Copy link

これは通知自体は届いてしまってもOKで、その後のアプリを開いた際の挙動でハンドリング(「ブロックしているユーザーなので見れない」などのアラート表示を出すなり?)、というような認識で合っていますか?

はい、そこまでできればGOODです!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request functional issue Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants