Support for multiple subscriptions topics

[rohit3d2003]

State your question I have a two tables 'Event' and 'Invitee' and I am subscribing to 'OnCreate' mutation for both these tables. I have a common method in which I call the subscription for these two individual methods but only last subscription works while the other one never trigger. I tried changing the order and same result (last one works). Questions:

1. Are multiple subscriptions supported? If yes, what am I doing wrong here?
2. Is there a way to filter the subscription during subscribing process instead of filtering it based on the results of the subscription?

Provide code snippets (if applicable)

Environment(please complete the following information):

• AppSync SDK Version: [e.g. 2.6.21] 2.8.0
• Dependency Manager: [e.g. Cocoapods, Carthage] Cocoapods
• Swift Version : [e.g. 4.0] 4.0

Device Information (please complete the following information):

• Device: [e.g. iPhone6, Simulator] Simulator
• iOS Version: [e.g. iOS 11.4] iOS 12.0
• Specific to simulators: iPhone XR

[palpatim]

Hi @rohit3d2003,

We definitely support multiple subscriptions--you can see an example in our SubscriptionStressTestHelper where we have 40 active subscriptions, each monitoring upvotes for a different post.

The root of the problem is that you're discarding the subscription watcher--you need to maintain a reference to watch active subscriptions.

I think the issue was probably caused by our documentation example, that implies that you don't need to do anything with the watcher other than ignore it, which is misleading.

If this does solve the problem, I'll recharacterize this issue as a bug in our documentation, and fix the code sample to be clearer about the fact that subscription watchers must be retained.

[rohit3d2003]

@palpatim - Thanks for helping me out! So basically, I need to maintain a reference to each type of subscription. So in the above scenario, I need to have a class level object (one for OnCreateInvitee & second for OnCreateEvent) or is there a generic Watcher that I can create at class level to hold the reference.

Also, it seems like the default generated subscription does not allow any parameters to be passed in while subscribing to a particular topic. Do I need to specify the subscriptions manually in schema.graphl file?

[palpatim]

So basically, I need to maintain a reference to each type of subscription.

Actually, a reference to each individual subscription. For example, a "type of subscription" might be "a post has been upvoted". An individual subscription might be "post 123 has been upvoted."

So in the above scenario, I need to have a class level object (one for OnCreateInvitee & second for OnCreateEvent) or is there a generic Watcher that I can create at class level to hold the reference.

I'd probably recommend an instance, rather than a class, level variable, since those are going to be destroyed when your containing object is destroyed, as opposed to a class variable that you'll have to make special efforts to release them. For example, a common use case is to subscribe in a ViewController's viewDidLoad method and hold onto the subscription reference in an instance variable. Then when the VC is deinitialized, it will release the subscription references (assuming that your handlers are weakly referencing self.

Also, it seems like the default generated subscription does not allow any parameters to be passed in while subscribing to a particular topic. Do I need to specify the subscriptions manually in schema.graphl file?

Correct, you'd pass subscription parameters just like a mutation or query. You can see general instructions here: https://docs.aws.amazon.com/appsync/latest/devguide/real-time-data.html#using-subscription-arguments

[rohit3d2003]

@palpatim - Thanks a lot! It makes lot of sense now. I have created a static instance of a class and all the watchers will live inside this instance as long as app is running. Do I still need to release them?

[palpatim]

@rohit3d2003

The appropriateness of a static provider will depend on your use case--if your app users can log in and out, it might be better to have an AppSync client, and associated watchers, as instance rather than class variables, so they can be tied your user's login state.

But if you are truly only using the static handles, then manually releasing them is not necessary. Do note that they will continue to update even if they aren't visible (e.g., if you set up watchers on a MasterViewController, but are currently displaying a DetailViewController, then the watcher would continue to process incoming events, which might have unanticipated UI side effects).

[stale[bot]]

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.