Add support for the new notification center #196

Closed
denschub opened this Issue Aug 25, 2012 · 13 comments

Comments

Projects
None yet

The new notification center at /notifications is pure awesomeness and it would be cool if we would have those notifications in the Android app, too.

Would be neat if there are notification counters in the already present Repositories tab, per entry.

I believe we need to wait for the GitHub API to support this feature..

In particular, it would be lovely to get Github notifications as notifications in the notification center on the android device, rather than having to open the app in order to view them. Just another way to spare our poor email inboxes.

Any work on this? It would be great, if I could see notifications on my Android device.

👍

Contributor

justinmuller commented Oct 29, 2013

👍

+1

@fadils fadils added the Feature label Feb 10, 2015

@Meisolsson Meisolsson added this to the 0.2.0 milestone Aug 23, 2016

Contributor

Meisolsson commented Oct 7, 2016

Ok, I've been thinking about this quite a bit. I feel like it's kind of empty to just add a notification list and it would almost be better to implement the whole flow (native notifications and list in app).

I see two options and a possible flow for each.

  1. The app pulling data from GitHub at set interval (configurable).
    • Pros:
      • All data is on the device
    • Cons: (Yes, most of this can be connected to battery)
      • Depending on interval there can be huge battery drains
      • Lot's of small network requests (drains battery and data plan)
      • Doze mode will stop us from fetching when it's on
      • If the same user has many devices we pull multiple times (Rate limits!)
  2. We make use of FCM (Firebase Cloud Messaging) and let a backend pull data from GitHub at an interval.
    • Pros:
      • We pull once per user (Once per minute is 60 requests per hour, GitHub allows 5000 if authed)
      • No battery to drain, FCM handles all of that
    • Cons:
      • Server needed
      • Pulling for lots of users can get slow

Thoughts?

mderazon commented Oct 7, 2016

I think it's very lame of GH to only offer polling as an option.
Anyway, their docs say this:

Notifications are optimized for polling with the "Last-Modified" header. If there are no new notifications, you will see a "304 Not Modified" response, leaving your current rate limit untouched. There is an "X-Poll-Interval" header that specifies how often (in seconds) you are allowed to poll. In times of high server load, the time may increase. Please obey the header.

Maybe another option that will require a server side component as well will be using pubsubhubbub ?

Last, maybe a clever hack with the email notifications - listen for email from notifications@github.com and then poll the api. Not sure if that would even be possible in Android.

p.s. I opened this issue, I think it could be nice if GH implemented this.

I wouldn't want to expose my data to a third-party service. I also don't need push notifications, just manual refresh is fine. I use emails at the moment.

On 7 October 2016 12:11:17 CEST, Henrik Olsson notifications@github.com wrote:

Ok, I've been thinking about this quite a bit. I feel like it's kind of
empty to just add a notification list and it would almost be better to
implement the whole flow (native notifications and list in app).

I see two options and a possible flow for each.

  1. The app pulling data from GitHub at set interval (configurable).
    • Pros:
      • All data is on the device
    • Cons: (Yes, most of this can be connected to battery)
      • Depending on interval there can be huge battery drains
      • Lot's of small network requests (drains battery and data plan)
      • Doze mode will stop us from fetching when it's on
  2. If the same user has many devices we pull multiple times (Rate
    limits!)
  3. We make use of FCM (Firebase Cloud Messaging) and let a backend pull
    data from GitHub at an interval.
    • Pros:
  4. We pull once per user (Once per minute is 60 requests per hour,
    GitHub allows 5000 if authed)
    • No battery to drain, FCM handles all of that
      • Cons:
      • Server needed
      • Pulling for lots of users can get slow

Thoughts?

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#196 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Contributor

Meisolsson commented Oct 7, 2016

The push part would be optional independent of which option we go for.

Contributor

Meisolsson commented Oct 7, 2016

@mderazon The email part might be possible but would require users to turn on email notifications. So that option is a no.

I hadn't read up on the X-Poll-Interval nor the Last-Modified but those will clearly get used.

The PubSubHubHub would require us to bind to each repository and i don't think it would mimic notification correctly.

@Meisolsson Meisolsson closed this Apr 26, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment