APNS for when events are scheduled

[coffeecoffeecoffeecoffee]

APNS for when events are scheduled

[jamescmartinez]

Definitely.

You'd start by persisting the list of events -- could be Core Data, but really a KV store would be sufficient; PinCache is one I used to use several years ago, though I'm not sure what the best is in 2019. You'd then implement background refresh which would fetch the most recent events, persist them in the store, and if there are changes/updates send a notification to the user.

☝️ Overcast does notifications this way, for example.

[jerrytdev]

👍local notifications

[jamescmartinez]

@drewvolz suggested this article when we discussed this approach at lunch today: https://blog.githawk.com/2018/10/02/Notifications-and-Background-Fetch.html

[jamescmartinez]

This is a tough one since we allow multiple groups the site but the coffee app is only for the SF Coffee group.

Traditionally, this would be done on a user-subscription basis. For example, assuming Roderic is a member of SF Coffee and SF Beer, we would send notifications to Roderic for those two groups; this is in a PR that @stratigos and I worked on but never finished.

The quick and dirty solution for the SF Coffee app, however, might be to hardcode the SF Coffee meetup as the only one that sends pushes. This would solve our problem for now, but it would be a nightmare to maintain (both on server and on iOS) if we ever want to add support for multiple group notifications. I don’t like this but it would work.

A third solution would be a sort of hybrid where we have people login to the iOS app, subscribe them to the SF Coffee group in the app, and then continue with the “traditional” implementation above. This would require a new API and some additional work on the app, but the code and data server-side would remain clean.

Thoughts?

[rodericj]

Couldn't you just have a push notification per group and have users in app individually subscribe on a per feed basis? Like: "I only want to hear from SF-Coffee", then whenever an event is created in that group you send out the push to all of the tokens that have requested to be sent notifications for that group?

Regarding the third solution: We would most definitely need a new API in order to get the APNS token from the device. Login can be done through CloudKit with no UI changes.

I'm going to re-read this but I'm kind of thinking the user-subscription basis works. How far along did y'all get?

[jamescmartinez]

Yes, you're exactly right. It would be on a channel-by-channel basis with the channel, in this case, being a "group".

The hybrid option I'm thinking of in more detail is really the first option above but having the app take care of the subscribing automagically ✨. Here's what that might look like:

1. User opens app
2. User logs in with Twitter
3. The app automagically ✨, behind the scenes, adds the user as a "member" of SF Coffee and subscribes them to notifications. This prevents the user from needing to select the group (as they currently need to do on the website)
4. Profit

The new endpoints would be something like POST /groups/:id/memberships to create a new membership, and POST /devices with the device push identifier to create a new device for push notification subscriptions.

[rodericj]

I would avoid using twitter login. For http://magicphotos.app we use fetchuserrecordidwithcompletion. For a brief see:the loginless blog post

So basically:

1. User opens the app
2. App gives us the user's cloudKit token
   • If they are not logged into iCloud (like ~0% of users, END)
3. App asks user to accept push notifications (again only if we get the token)
4. upon accepting App sends push token to server
5. app adds them as member of sf-coffee and subscribes them
6. Profit.

Do we still need both POST /groups/:id/memberships and POST /devices? Maybe the later is PATCH /devices?

[jamescmartinez]

The reason we use Twitter login is to have a concept of a "user" which supports group membership and other, undeveloped, features. I'm not saying this is the best method (other things could work here), but it's the one we have. I'm open to changing this.

The iCloud method/blog post you linked only works on iOS; the coffee site is available on the web as well, with other groups that aren't iOS Coffee (or even iOS specific at all). I want to continue to support these diverse use cases. If we use this method for the iOS app, then the site would have to support a one-off exception specific to this app which is more inline with the second "hardcoded" option I described above. As I mentioned before I don't love this, but I'm also not 100% opposed to it.

Yet ANOTHER solution™️ would be local notifications based on background fetching the updated API, watching for changes, and sending a local notification when there's a change. 🤷‍♂️

[rodericj]

I would be super interested in the local notification approach. It limits implementation on the server significantly. I wonder how reliable that is. I’d like to look into that.

I get the iCloud concern tho