Notification-based Invitation System #32

New issue

Closed

opened 2026-05-19 05:03:28 +00:00 by foravo_admin · 1 comment

foravo_admin commented

2026-05-19 05:03:28 +00:00

Owner

Imported from GitHub issue StanfordCS194/spr26-Team-22#49.

Source: https://github.com/StanfordCS194/spr26-Team-22/issues/49
Original author: @nriedman
Original state: closed

Summary

Based on the feedback we got from the Customer Discovery interviews, we decided to move away from a pre-filled iMessage text as the mechanism for sending an invitation. Instead, we should use Push notifications between users, assuming all parties have the app installed. This way, when User A accepts a suggested activity with User B, the following occurs in order:

User B receives a notification from Eta that says something like "User A has invited you to Coffee at 3pm".
User B determines if they are available and interested, and if so accept the invitation through Eta.
User B sees Coffee with **User A** as an activity in their upcoming dashboard.
User A receives a notification from Eta saying "User B has accepted your invitation for Coffee at 3pm".
User A sees Coffee with **User B** as an activity in their upcoming dashboard.

We can continue to iterate on the specifics of the UI for these steps (for example by adding "Accept" or "Decline" as a quick action linked to the push notification), but for the purposes of Demo Day 1, the basic flow from the perspective of User A is all we need.

Requirements

Implement the local push notification system from the perspective of User A. When User A accepts a suggestion, they see the following:

A UI on the suggestions page indicating an invitation has been sent to User B. User A should understand that this is an asynchronous operation, and that they can expect to hear back from Eta once User B has accepted or declined the invitation.
The activity is visible as "Pending" in the upcoming events dashboard.
After a short simulated delay (~5 sec.), a local push notification indicates User B has accepted the invitation.
The activity is visible as "Confirmed" in the upcoming events dashboard.

For Demo Day 1, we simplify the system to use local notifications. In the future, we will need to make the system more complex by sending real push notifications across devices. With this in mind, the system should be designed in an extendible way so that we can move to remote (e.g. server driven) push notifications without significantly refactoring other parts of the app.

Notes

This will progress in conjunction with work on #48.

Imported from GitHub issue `StanfordCS194/spr26-Team-22#49`. Source: https://github.com/StanfordCS194/spr26-Team-22/issues/49 Original author: @nriedman Original state: closed  --- ## Summary Based on the feedback we got from the Customer Discovery interviews, we decided to move away from a pre-filled iMessage text as the mechanism for sending an invitation. Instead, we should use Push notifications between users, assuming all parties have the app installed. This way, when **User A** accepts a suggested activity with **User B**, the following occurs in order: 1. **User B** receives a notification from Eta that says something like "**User A** has invited you to Coffee at 3pm". 2. **User B** determines if they are available and interested, and if so accept the invitation through Eta. 3. **User B** sees `Coffee with **User A**` as an activity in their upcoming dashboard. 4. **User A** receives a notification from Eta saying "**User B** has accepted your invitation for Coffee at 3pm". 5. **User A** sees `Coffee with **User B**` as an activity in their upcoming dashboard. We can continue to iterate on the specifics of the UI for these steps (for example by adding "Accept" or "Decline" as a quick action linked to the push notification), but for the purposes of Demo Day 1, the basic flow from the perspective of **User A** is all we need. ## Requirements Implement the local push notification system from the perspective of **User A**. When **User A** accepts a suggestion, they see the following: 1. A UI on the suggestions page indicating an invitation has been sent to **User B**. **User A** should understand that this is an asynchronous operation, and that they can expect to hear back from Eta once **User B** has accepted or declined the invitation. 2. The activity is visible as "Pending" in the upcoming events dashboard. 3. After a short simulated delay (~5 sec.), a local push notification indicates **User B** has accepted the invitation. 4. The activity is visible as "Confirmed" in the upcoming events dashboard. For Demo Day 1, we simplify the system to use local notifications. In the future, we will need to make the system more complex by sending real push notifications across devices. With this in mind, the system should be designed in an extendible way so that we can move to remote (e.g. server driven) push notifications without significantly refactoring other parts of the app. ## Notes This will progress in conjunction with work on #48.

foravo_admin closed this issue

2026-05-19 05:03:28 +00:00

foravo_admin commented

2026-05-19 05:03:31 +00:00

Author

Owner

Imported from GitHub issue comment StanfordCS194/spr26-Team-22#49:4331806491.

Source: https://github.com/StanfordCS194/spr26-Team-22/issues/49#issuecomment-4331806491
Original author: @nriedman

@jasagye I've been working on #48, and did a bit of thinking about the interface between our two features. To decouple our components and allow you to make decisions about how event updates are handled on the system side, I was thinking we could do a Publisher-Subscriber-like system.

The Upcoming Events dashboard is a consumer that subscribes to event updates. The dashboard does this by looking at the SwiftData-backed ScheduledHangout, and updating the UI when a new computed property status changes. status is calculated based on the state of the ScheduledHangout, so is consistent by construction.

Then, on the other side, the Invitation System is a Publisher. It notifies all other components that are subscribed to a given ScheduledHangout by modifying the hangout's state (e.g. the Invitation System knows when an invitee has accepted an invitation, and will increment a counter in the ScheduledHangout). The specifics would be up to you on the Publisher side.

I mention this here to see if you're down to design the interface between our features this way! I like it because it decouples our two systems (or any systems that need to communicate about ScheduledHangouts), but wanted to check in with you before moving forward. Let me know if you have any thoughts!!

Imported from GitHub issue comment `StanfordCS194/spr26-Team-22#49:4331806491`. Source: https://github.com/StanfordCS194/spr26-Team-22/issues/49#issuecomment-4331806491 Original author: @nriedman  --- @jasagye I've been working on #48, and did a bit of thinking about the interface between our two features. To decouple our components and allow you to make decisions about how event updates are handled on the system side, I was thinking we could do a [Publisher-Subscriber](https://tejaswinimr.medium.com/understanding-publisher-and-subscriber-protocols-in-combine-swift-01c86d46e402)-like system. The Upcoming Events dashboard is a consumer that subscribes to event updates. The dashboard does this by looking at the SwiftData-backed `ScheduledHangout`, and updating the UI when a new computed property `status` changes. `status` is calculated based on the state of the `ScheduledHangout`, so is consistent by construction. Then, on the other side, the Invitation System is a Publisher. It notifies all other components that are subscribed to a given `ScheduledHangout` by modifying the hangout's state (e.g. the Invitation System knows when an invitee has accepted an invitation, and will increment a counter in the `ScheduledHangout`). The specifics would be up to you on the Publisher side. I mention this here to see if you're down to design the interface between our features this way! I like it because it decouples our two systems (or any systems that need to communicate about `ScheduledHangout`s), but wanted to check in with you before moving forward. Let me know if you have any thoughts!!