そして物語は何度目かのアプリ内通知再実装を迎える

というタイトルでKyoto.なんか #2で発表してきました．

そして物語は何度目かのアプリ内通知再実装を迎える / Reimplement in app notification // Speaker Deck

スライドの内容としては，アプリ内通知 (Twitter appで言うところの「通知」タブにあたる部分) のサーバサイドを実装する際にどういう問題があって，それをどういう風に実装したかという葛藤の記録となっています．

Webアプリケーションやスマートフォンアプリケーションを書いていると，そこそこの確率でアプリ内通知を書くことになると思うんですが，ところがどっこい「実際にどういう風に実装しているか」みたいな知見が共有されている感じがあまりありません．みんな実装しているはずなのに，ググってもあまり情報が出てこなくて寂しい．地味な機能だから？
という思いがあり，そこら辺アプリ内通知周辺の技術交流・意見交換などしたいなあというモチベーションでこの度発表してみた次第です．賽は投げられた．

ところで，この発表の最後で言おうと思っていたのに言っていない事があったのでこの場に書きますが，実際は「アプリ内通知」というか「通知タブ」のようなものはアプリケーションが個別に自作すべきものではないのでは？　と思っています．
iOSやAndroidには受け取ったpush通知を貯めて表示する通知センター的な領域が用意されているので，そうしたOSが提供してくれている機能に乗るようにアプリケーションを作成すればこんなに悩まなくても済みます (例えば今回の場合だと，push通知を送るだけ送るようにしておいて，クライアントが通知を貯めておくようにしておけばサーバサイドで通知情報を保持する必要がなくなる)．

とにかく，OSが提供してくれるものを再実装するのはやめた方が良くて，例えば通知センターや，通知のおやすみモードなどはアプリが個別で持つべきではないと思っている
— 報酬は折半です (@moznion) 2016年8月23日

通知に限らず，他にもそうしたコンポーネントと言うのは様々あると思っていて，OSが提供してくれている機能で要件を満足できるのであればそれを活用するのが良いんじゃないかな，と思っています．
とはいえアプリケーション・サービスの特性によってはそうも言っていられないので，今回のように自作することになります．ケースバイケースと言えるでしょう．OSの通知センター使いたかった……

Kyoto.なんかは色々な技術的な話を聞けてとても有益でした．
特にid:r7kamuraさんのamakanのシリーズ判定の話がすこぶる面白かった．