0

When didReceiveStatus is called after subscribing to a channel, We are not able to retrieve the channel(s) that was just subscribed.

PNSubscribeStatus.data.subscribedChannel or PNSubscribeStatus.data.actualChannel are always null and PNSubscribeStatus.subscribedChannels gives all currently subscribed channels and not the ones that triggered the didReceiveStatus callback.

What are we doing wrong here ?

ebelrose
  • 3
  • 1

3 Answers3

0

In SDK 4.0, didReceiveStatus returns a PNStatus, which according to the class documentation doesn't contain that extra information unless there's an error condition. For our application, we use that handler to monitor connection status to the PubNub server.

Mathew Spolin
  • 371
  • 1
  • 11
  • We need to send a specific message to the channel after the subscription. The aim is to send it from the callback so we are sure that we are correctly subscribed to receive related answers from other devices – ebelrose Apr 16 '16 at 21:59
  • I'm sure you've considered this but you could probably just initiate that from the completion handler of the subscribe call. – Mathew Spolin Apr 16 '16 at 22:06
  • Is there any completion handler with the subscribe call ? Can't see that in the documentation. – subscribeToChannels:withPresence: – subscribeToChannels:withPresence:clientState: – ebelrose Apr 17 '16 at 16:28
  • Sorry, I was confusing this with another method. Have you tried sending the message on the given channel after the call returns and checking to see if you receive it as a guarantee that you are subscribed correctly? – Mathew Spolin Apr 20 '16 at 18:30
  • The thing is that we are not really at ease with this as subscription call is also asynchronous so it would be good to have callbacks methods with the original request info or callbacks block in which you can pass objects as for message publishing. – ebelrose Apr 21 '16 at 15:12
0

PubNub Message Received Channel Name in iOS

You should be able to get the channel that you received the message on but getting it depends on whether you are subscribed to the channel or to a channel group that contains the channel. This is sample code from the PubNub Objective-C for iOS SDK subscribe API Reference:

- (void)client:(PubNub *)client didReceiveMessage:(PNMessageResult *)message {
  
    // Handle new message stored in message.data.message
    if (message.data.actualChannel) {
  
        // Message has been received on channel group stored in
        // message.data.subscribedChannel
    }
    else {
  
        // Message has been received on channel stored in
        // message.data.subscribedChannel
    }
    NSLog(@"Received message: %@ on channel %@ at %@", message.data.message,
          message.data.subscribedChannel, message.data.timetoken);
}

If you need other channels that the client is subscribed to, you can call the where-now API.

If you need to be more dynamic about what the reply-to channel should be, then just include that channel name in the message when it is published, assuming the publisher has prior knowledge about which channel this is. Or you can do a just in time lookup on your server as to which channel to reply to.

Community
  • 1
  • 1
Craig Conover
  • 4,710
  • 34
  • 59
  • Hi Craig, This is not answering our question. We didn't ask to retrieve the channel when receiving a message, we ask to retrieve the channel from a **subscription callback** aka didReceiveStatus – ebelrose Apr 18 '16 at 12:38
0

Here is PubNub support answer on this :

Actually status.data.subscribedChannel and status.data.actualChannel dedicated to presence events and messages receiving callbacks where information about sources of event is important.

In -client:didReceiveStatus: client doesn’t give information about particular channel on which client has been subscribed. If client will start track this information, there is no guarantee what it will return expected value (as developer expect some channels to be there). In previous version (3.x) all this information has been tracked, but because it can be modified at any moment – result sometimes was unpredictable.

Subscribe can be done in sequence of methods (one after another) like: subscribe A1, subscribe C1, subscribe B1 and B2, unsubscribe C1 and B1 – this as result will end up with single call of -client:didReceiveStatus: with resulting set of channels.

It always best practice just to check whether your channels is in s_tatus.subscribedChannels_.

My comments: The point of having asynchronous process is exactly not to think this as sequence of methods... We can not have the guaranty that subscriptions are done in the exact same order as the subscription request unless we block other subscription request until the previous one is done.

ebelrose
  • 3
  • 1