Githawk: プッシュ通知

これには、ユーザーを認証し、通知を送信するために新しい通知を定期的にポーリングするWebサーバーに保存する必要があるという点で、かなりの作業が必要になります。デバイスでのバックグラウンドフェッチの方が幸運だと思います。のチケットがあります！

でもこれが好きだろう

うん、私はあなたを感じます。 一時的な解決策としては、アプリにバッジを付けるbgジョブが適していると思います。 bgジョブでローカルプッシュ通知をスケジュールすることもできます！ しかし、私にとって個人的にプッシュするのは面倒です。

ただし、これらすべてを設定に入れることができます。

ポーリングサーバーはもっと長期的に望まれていますか？ 私はまさにこの目的のために一度作った😅。 私のアプローチがどれほど正気だったかはわかりませんが、もう一度見てみると面白いでしょう。

時々（ポーリングサービスのように）、どのソリューションが最適かを理解するためにUXを検討する傾向があります。

私にとって、答えられるべき質問は、人々が1回のセッションでアプリにどれくらいの時間を費やすかということです。 私のように一度に数分なら、ポーリングはおそらくやり過ぎでしょう。

私は彼のバックグラウンドフェッチで100％です。 私は過去数週間にわたってこれを使って徹底的なテストを行ってきましたが、非常に信頼できることがわかりました。 1日に数回使用しているアプリでほぼ1時間ごとにトリガーします。

私はそれが実行可能な長期的な解決策でもあると思います。

アプリを使用していないときに新しい通知がいつあるかを知ることが目標のように思えます。 とにかく、アプリは約10分間だけ開いたままになります（要求した場合）。 しかし、そうでない場合、システムは私自身のテストでより良いバックグラウンド優先度を与えるように見えます。

バックグラウンドフェッチで見つけたメモ。 （アップルの仲間からのいくつか）
バックグラウンドフェッチはほとんど文書化されていませんが、私が遭遇したいくつかのヒントは、アプリケーションの起動時間やエネルギー使用量などです。

このenvvarを追加すると、Xcodeのデバッグコンソールでアプリを起動したときに一連の統計情報が表示されます。 本当に便利です。 彼らはあなたのアプリが400ms以内に起動できるはずだと示唆しています。私は個人的に2〜300を目指す傾向があります。

エネルギー使用量は、XcodeまたはInstrumentsから明らかに確認できます。

バックグラウンドフェッチAPI（ご存知のとおり）には、完了時に呼び出す必要のあるcompletionHandlerがあります。 以前は、ほとんどの場合、 .newDataで呼び出していました。 これは間違いでした。 これをどのようにランク付けするかは正確にはわかりませんが、何もなかったときに.noDataを呼び出すことが重要です。 フェッチ間隔を改善します。

主なことは、これらの数値を低く保つことです。 アプリを非常に迅速に起動でき、バッテリーをほとんど使用せず、かなり迅速に終了できる場合、システムはより多くのバックグラウンド時間を与える傾向があります。

繰り返しになりますが、これは私自身の限られたテストですが、バックグラウンドフェッチの実装が成功したいくつかのアプリに長年取り組んできました。

+1の目標は、アプリにバッジを付け、アプリにないときに新しいものがある場合はオプションで通知することです。 今のところbgタスクに固執しましょう。

バッジが追加されましたが、ローカル通知の追加を追跡するために、今はこれを開いたままにしておきます。 かっこいいと思います。 すでに通知された内容を追跡する必要があるため、やや複雑です。 また、「4つの新しい通知」のようなものにそれらをバッチ処理する可能性があります。

たぶん、レポで通知を分割することもできますか？

@rnystromとてもかっこいい

質問：アプリのホーム画面にバッジが表示されましたが、開いたときに：tada：アイコンが表示され、更新するにはプルする必要がありました。これが現在の動作方法ですか？

また、バッジをオフにしましたが、まだ表示されています😔

@Sherloukは、[設定]、[通知]、[空き時間]でオフにできます。[通知を許可する]のチェックを外します。

私はそれを理解していますが、アプリの所有者として、ユーザーがそのレベルでそれをオフにすることは、将来的に他の方法で通知を利用したい場合には本当に悪いことです-その設定をより適切にアプリ内で制御する必要があります。

「バッジをオフにする」と表現されている、または少なくとも私が解釈しているトグルもあります-これは機能しません

そうです、その間にこれを修正するつもりでした:)

@Sherloukなので、設定でdisBledを指定しましたが、まだバッジが付いていますか？ ああ、私は理由を知っていると思います。 修正します。

ローカル通知は大歓迎です。 私は現在、（有料の）アプリCodeHubを使用して通知を取得していますが、通知をタップするのではなく、代わりにGitHawkを開くことを忘れないでください。

ローカル通知の場合は+1。

私は実際のサーバー側のプッシュ通知については絶対に100％です。 GitHubがメッセージングサービスではないことは知っていますが、反応時間は依然として重要であり、応答が速いと、変換をより速く実行し、問題をより早く解決するのに役立ちます。 私は実際に困惑しています。GitHub自体はまだ公式アプリをプッシュで提供していません。

_{GitHawkで送信}

私が予想する主な問題はレート制限だけです。アプリのアクティブユーザーであるだけで、すでにレート制限にかなり近づいています。 これは、数分ごとに通知をポーリングする必要がありません。 技術的にはそれほど難しいことではありませんが、githubアプリをロックアウトせずにそれがどのように機能するかを理解する必要があります！

_{GitHawkで送信}

通知にはCodeHubを使用しています。 彼らがそれをどのように行うのかはわかりませんが、機能をアクティブにするためにお金を払わなければなりませんでした。 代わりにGitHawkを開くことを忘れないでください。

さあ、これもオープンソースです： CodeHub-Push

_{GitHawkで送信}

通知のためだけに2つ目のgithubアプリを設定できるかどうか疑問に思います。 2回ログインする必要がありますが、レート制限の問題は軽減されますか？

_{GitHawkで送信}

それとも、それを試してみて、それがほとんどの人にとって問題であるかどうかを確認するだけの場合ですか？ これをより適切に追跡すると便利な場合があります。ファブリックを使用して、ユーザーがレート制限を超えたときにイベントを投稿して、問題が発生したときにそれがわかるとしたらどうでしょうか。 ここでも、存在しない問題の代替ソリューションを導入しても意味がありません。

_{GitHawkで送信}

ほとんどのAPI呼び出しはどこから来ていますか？ 一部のデータをキャッシュすることでそれらを最適化することは可能ですか？

_{GitHawkで送信}

CodeHub-Pushを見ると（ @schrodincatに感謝します！）、彼らのアプローチは_per-app_（GitHawk）ではなく_per-user_（私、あなたなど）のようです。したがって、レート制限は問題になりませんか？

私が見ているレート制限の問題はユーザーごとです😔私たちは、間違いなく過去に、最適化を検討する必要がありますが、最終的には50の通知を開くと、多くのAPI呼び出しが発生します！ それについてできることはあまりありません！

_{GitHawkで送信}

@rnystromこのマージでは、Githubのリポジトリの更新についてiOSのGitHawkからプッシュ通知を受け取りますか？

@mesqueebWebサイトで通知を受け取ったものは何でも。