Githawk: Push Notifications

This would require quite a lot of work in terms of having to authenticate users and store this in a web server polling regularly for new notifications in order to send a notification - think we’ll have more luck with background fetching on devices, which i know there’s a ticket for!

Would love this though

Yup, I feel you. I think a good temp mid solution would be a bg job that badges the app. We could even schedule local push notifications with the bg job too! But for me personally pushes would be annoying.

However we could put all of this in settings.

Is a polling server desired more long-term? I made one for exactly this purpose once 😅 . Not sure how sane my approach was, but taking another look at it would be interesting.

Sometimes (like with polling services) I tend to consider the UX in order to understand what solution would be best.

For me, the question to be answered would be how long do people spend in the app for a single session. Because if like me its a few mins at a time, polling would probably be overkill tbh.

I'm 100% with he background fetches though. I've been doing thorough testing with this over the past couple of weeks and found it to be quite reliable. Triggering almost every hour or so with my app that I'm using a couple of times a day.

I think its a viable long term solution as well tbh.

Sounds to me like the goal is to know when there are new notifications when I'm NOT using the app. Apps only stay open for around 10 mins (if you request it) anyway. But when you don't the system appears to give you better background priority in my own testing.

Notes I found on background fetch. (Some from an Apple fellow)
Background fetch is largely undocumented, however a few of tips I've come across are things like Application Launch times and Energy Usage.

By adding this env var, you'll see a bunch of statistics when your app launches in Xcode's debug console. It can be really useful. They suggest your app should be able to launch in under 400ms I tend to aim for 2-300 personally.

Energy Usage can obviously be checked from Xcode or Instruments.

The background fetch API (as I'm sure you know) has a completionHandler you need to call when you're done. Previously I had mostly just called it with .newData in all cases. This was a mistake. Not sure exactly how it ranks this, but its important to call .noData when there wasn't any. Improves fetch intervals.

The main thing is to keep these numbers low. If the app can be launched quite quickly, use little battery and finished fairly quickly the system tends to give you more background time.

Again this is in my own limited testing, but I have worked on several apps with successful background fetch implementations over the years.

+1 that the goal is to badge the app and optionally notify when there are new things when not in app. Lets stick with bg tasks for now.

Badges added but I'll leave this open for now to track adding local notifications. I think that'd be cool. Semi complicated because we have to track what has already been notified. Also probable batching them into one that says like "4 new notifications".

Maybe we can even split the notifications by repo?

@rnystrom very cool

question: the app got a badge on the home screen but when I opened it, got the :tada: icon and had to pull to refresh.. is that the current way it works?

Also I have the badge turned off, but I'm still getting it showing up 😔

@Sherlouk can u turn it off with Settings / Notifications / Freetime .. uncheck Allow Notifications

I get that, but as an app owner myself having users turn it off at that level is really bad in case you want to take advantage of notifications in other ways further down the line - Should have better in-app control over that setting.

There is also a toggle which is worded, or at least interpreted by me, as "Turn off the badge" - Which doesn't work

Right right, I meant for you to fix this in the meantime :)

@Sherlouk so you gave it disBled in settings but it's still badging? Ah shit I think I know why. Will fix.

Local notifications would be very welcome. I currently use (paid) app CodeHub to get notifications and then have to remember not to tap them but to open GitHawk instead.

+1 for local notifications.

I’m absolutely 100% for real server-side push-notifications. I know GitHub not a messaging service, but reaction time is still important and fast response can help to get conversions going faster and therefore resolve issues faster. I’m actually baffled GitHub itself still hasn’t provided an official app with push.

_{Sent with GitHawk}

The main issue I foresee is just rate limits, we've already come quite close to hitting it just with being an active user in the app! That's without polling for notifications every few minutes! Technically it's not too difficult, but we'd need to work out how that would work without locking out the github app!

_{Sent with GitHawk}

I use CodeHub for notifications. I'm not sure how they do it but I had to pay to activate the feature. I just have to remember to open GitHawk instead.

Here you go, it’s open source too: CodeHub-Push

_{Sent with GitHawk}

I wonder if we could set up a second github app just for notifications? It would require people to login twice, but would mitigate the rate limit issue?

_{Sent with GitHawk}

Or is it just a case of we try it out and see if it's even an issue for most? Better tracking on this could be handy - what if we used fabric and post an event when a user maxed out rate limit so we know when it's an issue? Again no point putting in alternative solutions to a non existence problem!

_{Sent with GitHawk}

Where are most API calls come from? Is it possible to optimize them by caching some data?

_{Sent with GitHawk}

Looking at CodeHub-Push (thanks @schrodincat !) it seems their approach is _per-user_ (me, you, etc.) not _per-app_ (GitHawk), so rate limiting should not be an issue?

The rate limit issues I've been seeing are per user 😔 we should, and definitely in the past have, look at optimising stuff but ultimately if you open 50 notifications that's a lot of api calls! Not much we can do about that!

_{Sent with GitHawk}

@rnystrom With this merge, will we receive push notifications from GitHawk on iOS for any update in our repo's on Github?

@mesqueeb anything you receive a notification for on the website.