Chat push notifications missing

Sendbird Chat API/SDK Android
1

I’m using SendBird SDK 3.0.139 in my Android app. Some users are complaining of not receiving push notifications occasionally. I’ve tried to reproduce and got there though very rare. The case I faced was that when app is backgrounded, the SDK somehow didn’t disconnect user. Hence, as SendBird don’t send push notifications for online users, this user was not getting notifications for incoming messages. We are relying on SDK’s internal mechanism of disconnecting/reconnecting user when app switches between background and foreground.
Is it a known issue or am I missing something here?
Also, while trying to handle the disconnect/reconnect explicitly and disabling the internal mechanism, I found the handling to be complicated. Can we somehow just invoke the disconnect() explicitly without disturbing internal reconnect() mechanism?

2

Hi :wave: @Asem, welcome to the community!

We recently improved connection related mechanisms during foreground/background switching. Could you please try our latest version (3.0.154) and let us know if the issue persists?

For an explicit disconnect call, when do you want to call disconnect? Because generally, SDK manages disconnection-reconnection itself. If you wanted to use disconnect to solve the above-mentioned problem, please first try our latest SDK and let us know if it does not go away. We can then try other options :hugs:

I hope this was helpful. Please let us know if there’s any update!

3

Hey @Cjeon, Thanks for the quick reply.

Regarding the explicit disconnect() I’m thinking to implement it in
OnLifecycleEvent(Lifecycle.Event.ON_STOP) of Application class. In this approach, I’ll connect again on OnLifecycleEvent(Lifecycle.Event.ON_START) event. But I see that in this approach, there are some complication. For example, in default handling, we can just invoke send image message in onActivityResult while coming back from gallery/camera. SDK will itself handle the connection and message dispatching flow. But if we explicitly disconnect, we will have to handle this flow explicitly.

4

@Asem Hi Asem. Thank you for your reply. I believe we did not design our disconnect-reconnect mechanism for such a use case. But we can always modify our design if there’s a need. Could you please tell us more about why you want to call disconnect() in OnLifecycleEvent(Lifecycle.Event.ON_STOP)? Why do you try to use this approach instead of the default approach?
If it helps, roughly speaking, the default approach will disconnect upon activity pause and reconnect upon activity resume. So I think it will eventually disconnect on Application onStop and eventually connect on Application onStart.

Thank you for the reply, and please have a good day. :+1:

5

Hey @Cjeon, Thanks for the support. It was really helpful.
Currently, I’m following the default approach and have left the connection management on SDK. The explicit handling was intended to adjust for some rare case when SDK apparently fails to disconnect on Application onStop and hence push notifications are missed. I couldn’t find the definite steps to reproduce this issue though. But, for now, I’ll update the SDK to latest version i.e. 3.0.154 and keep an eye on this specific issue.
Keep up the active support and good work.
Cheers.

1 Like
6

Hey @Cjeon, It’s Asem again.
In an earlier conversation you mentioned that SDK by default disconnect upon activity pause and reconnect upon activity resume. Is it true for all the activities in app? I can’t see a way from docs to configure for some specific activities. Also, docs mentions to do SendBird.init() in Application.onCreate() so the context available to SendBird is Application level. Asking this because I want to maintain connection on a few of activities and not all.

7

Hi @Asem, I hope you are doing well. :grin:

Yes, it is true for all activities in the app. We currently do not support configuring this for only specific activities. Generally, this would not cost too much overhead or interfere with the app’s functions, but there could be always some edge cases. For such a case, we provide another init() function called Sendbird#initFromForeground(). This function does not have to be called from Application#onCreate(), but calling this from Activity’s onCreate will suffice.

However, please note that our official recommendation is to use Sendbird#init() because Sendbird#initFromForeground() was only recently added (3.0.149).

Please feel free to reply here if you have any more questions and have a good day! :+1:

8

Thanks for the response. I’m doing fine. Hope you, too, are doing great.
I’m thinking to optimise concurrent connections in my app in which chat is just one function. So, ideally I don’t want the user’s connection to stay open when he/she is doing other stuff in app. But, to achieve this, if I explicitly close the connection, then I’ll need to handle the reconnection as well on Activity’s/Fragments’s pause/resume. Is there a better approach to handle this use case?

9

Sadly I don’t think we currently offer an any better approach for such a use case. We thought that maintaining one network connection in an app would not cost that much. Other services like firebase messaging or many cloud loggers maintain the connection from the app launch to the termination (as far as I’m concerned).

However, if there is a need, we can always add new features. But to do that, I am sorry, but you have to contact a sales or solutions engineer to file an issue ticket. If you do, please attach a link to this post so that our team members can understand the context fast.

I’m sorry I was not able to provide more helpful information on this. I’ll update here if I find any helpful info for this. :+1:

10

Hi @Asem, here’s some additional notes/additional info from our team members:

  1. explicit disconnect will clear all info on the device (it’s similar to logout - we will not reconnect upon onResume) so please note this when you call explicit disconnect. (However, until the FCM push token is unregistered, the client will still receive push notifications)
  2. internal disconnect/reconnect mechanism has some delay to prevent too frequent disconnect/reconnect.
  3. If some users are disconnected while navigating their gallery/camera, you could consider using setAutoBackgroundDetection. Temporarily passing false to this method will stop automatic disconnect - and passing true again upon user’s return will enable automatic detection again.

Hope this was helpful! :hugs:

2 Likes
11

Hey @Cjeon

Thanks for the detailed response. It’ll be helpful in architecture design. I’ll do more thought work and if required, will contact a sales or solutions engineer as you suggested.

Cheers

1 Like