Githawk: 推送通知

这将需要大量工作，因为必须对用户进行身份验证并将其存储在网络服务器中，定期轮询新通知以发送通知 - 认为我们在设备上进行后台获取会更有运气，我知道有一张票！

不过会喜欢这个

是的，我感觉到你了。 我认为一个好的临时中间解决方案将是一个标记应用程序的 bg 工作。 我们甚至可以使用 bg 作业安排本地推送通知！ 但对我个人来说，推动会很烦人。

但是，我们可以将所有这些都放在设置中。

是否需要更长期的轮询服务器？ 我曾经为此目的制作了一个😅。 不确定我的方法有多理智，但再看看它会很有趣。

有时（比如投票服务）我倾向于考虑用户体验，以了解哪种解决方案是最好的。

对我来说，要回答的问题是人们在应用程序中花费多长时间进行一次会话。 因为如果像我一样一次几分钟，投票可能会有点过分。

不过，我 100% 支持他的背景获取。 在过去的几周里，我一直在对此进行彻底的测试，发现它非常可靠。 我每天使用几次的应用程序几乎每隔一小时左右就会触发一次。

我认为它也是一个可行的长期解决方案。

在我看来，目标是在我不使用该应用程序时知道何时有新通知。 无论如何，应用程序只能保持打开大约 10 分钟（如果您要求的话）。 但是，当您不这样做时，系统似乎会在我自己的测试中为您提供更好的背景优先级。

我在后台获取中找到的注释。 （一些来自苹果研究员）
后台获取基本上没有记录，但是我遇到的一些技巧是应用程序启动时间和能源使用情况。

通过添加这个 env var，当你的应用在 Xcode 的调试控制台中启动时，你会看到一堆统计信息。 它真的很有用。 他们建议您的应用程序应该能够在 400 毫秒内启动，我个人倾向于 2-300 毫秒。

显然可以从 Xcode 或 Instruments 中检查能源使用情况。

后台获取 API（我相信您知道）有一个完成处理程序，您需要在完成后调用。 以前，在所有情况下，我大多只是用.newData来调用它。 这是一个错误。 不知道它是如何排名的，但是在没有的时候调用.noData很重要。 改进获取间隔。

最重要的是保持这些数字低。 如果应用程序可以很快启动，使用很少的电池并很快完成，系统往往会给你更多的后台时间。

同样，这是在我自己的有限测试中，但多年来我已经开发了几个成功实现后台获取的应用程序。

+1 目标是标记应用程序，并可选择在有新事物时通知应用程序。 现在让我们坚持 bg 任务。

添加了徽章，但我暂时将其保持打开状态以跟踪添加本地通知。 我想那会很酷。 半复杂，因为我们必须跟踪已经通知的内容。 也可能将它们批量化为“​​4 个新通知”之类的内容。

也许我们甚至可以通过 repo 拆分通知？

@rnystrom很酷

问题：该应用程序在主屏幕上有一个徽章，但是当我打开它时，得到了 :tada: 图标并且不得不拉动刷新..这是它目前的工作方式吗？

我也关闭了徽章，但我仍然显示它😔

@Sherlouk你可以用设置/通知/空闲时间关闭它..取消选中允许通知

我明白了，但是作为应用程序所有者，如果您想以其他方式进一步利用通知，那么作为应用程序所有者我自己让用户在该级别关闭它真的很糟糕 - 应该对该设置有更好的应用程序内控制。

还有一个切换，它的措辞或至少被我解释为“关闭徽章” - 这不起作用

对对对，我的意思是让你同时解决这个问题:)

@Sherlouk所以你在设置中禁用了它，但它仍然是徽章？ 哎呀，我想我知道为什么了。 会修复。

非常欢迎本地通知。 我目前使用（付费）应用程序 CodeHub 来获取通知，然后必须记住不要点击它们，而是打开 GitHawk。

+1 用于本地通知。

对于真正的服务器端推送通知，我绝对是 100%。 我知道 GitHub 不是消息服务，但反应时间仍然很重要，快速响应有助于加快转换速度，从而更快地解决问题。 我真的很困惑 GitHub 本身仍然没有提供带有推送的官方应用程序。

_{与GitHawk一起发送}

我预见的主要问题只是速率限制，我们已经非常接近于成为应用程序中的活跃用户！ 无需每隔几分钟轮询一次通知！ 从技术上讲，这并不太难，但我们需要弄清楚如何在不锁定 github 应用程序的情况下工作！

_{与GitHawk一起发送}

我使用CodeHub进行通知。 我不确定他们是如何做到的，但我必须付费才能激活该功能。 我只需要记住打开 GitHawk 即可。

给你，它也是开源的： CodeHub-Push

_{与GitHawk一起发送}

我想知道我们是否可以为通知设置第二个 github 应用程序？ 它需要人们登录两次，但会缓解速率限制问题吗？

_{与GitHawk一起发送}

还是只是我们尝试一下，看看这对大多数人来说是否是个问题？ 对此进行更好的跟踪可能会很方便 - 如果我们使用结构并在用户达到速率限制时发布事件以便我们知道何时出现问题怎么办？ 同样没有必要为不存在的问题提供替代解决方案！

_{与GitHawk一起发送}

大多数 API 调用来自哪里？ 是否可以通过缓存一些数据来优化它们？

_{与GitHawk一起发送}

查看 CodeHub-Push（感谢@schrodincat ！）似乎他们的方法是 _per-user_ （我、你等）而不是 _per-app_ （GitHawk），所以速率限制应该不是问题吗？

我看到的速率限制问题是针对每个用户的😔 我们应该，而且过去肯定有过，看看优化的东西，但最终如果你打开 50 个通知，那就是很多 api 调用！ 我们对此无能为力！

_{与GitHawk一起发送}

@rnystrom通过这次合并，我们是否会在 iOS 上收到来自 GitHawk 的推送通知，以了解我们在 Github 上的 repo 中的任何更新？

@mesqueeb您在网站上收到的任何通知。