Please provide steps to reproduce the issue with user update because the next scenario works fine for me:
login
join default channel
add message listener
send message - message is received
update user - user is successfully updated
send message - message is received
logout
wait until channel is joined automatically again (it’s an expected behaviour because we need to reconnect socket after logout with a new settings and then resubscribe for all subscriptions including messaging)
send message - message is received
login
wait until channel is rejoined automatically again (it’s an expected behaviour because we need to reconnect socket after login with a new settings)
The issue with reconnect after the internet disconnects is now solved.
But there is still an issue when updating user with: [Backendless.shared.userService updateWithUser:]
We discovered that when the stay logged in flag is set: Backendless.shared.userService.stayLoggedIn = YES;
and when user update is called the joined channels join again.
It seems like that stayLoggedIn flag forces the socket to reconnect, on user update, whilst re-joining all joined channels.
For us, the stayLoggedIn flag in conjunction with validating user token doesn’t work as expected - even if we set the flag to NO, when the app relaunches the user token will still be valid.
Can you please expedite this issue with your development team? We need to release our app and this is one of the main issues we encounter.
As Hrvoje mentioned, the issue arises when the Backendless.shared.userService.stayLoggedIn = YES; flag is set.
Even though the disconnect issues have been fixed with some of the later builds, the problem where the flag is set causes the malfunction in PubSub subscription where it breaks completely, user cannot receive any messages anymore which is a dealbreaker for us.
I see another couple of builds after your last interaction with our dev, however they don’t seem to be related to our use case - can you confirm?
The ticket is in progress right now and the fix will arrive soon.
However, I’d ask you to provide steps of the expected and current behaviour to test the fix as close as possible to your scenario (as it was done in the first comment).
There is still a certain situation when RT messaging stops working (Swift-SDK v6.2.10.). Here are steps to reproduce the issue.
login user
connect to channel
add message listener
send message - the message is received
logout user
These next steps you need to do fast one after the other. You can wait for user to properly login but then you need to remove and add message listeners very fast.
The problem still isn’t fixed. After you do logout and then login there is a period when Backendless reconnects. You can track the Backendless connection with these listeners: Backendless.shared.rt addConnectEventListenerWithResponseHandler
and Backendless.shared.rt addDisсonnectEventListenerWithResponseHandler
After logout and then login, there are few seconds after Beckendless connects. If you add/remove message listners in a period when Backendless still isn’t connected they won’t work. If you add/remove message listeners after Backendless connect, it works fine.
Also on the note of the general Swift-Backendless SDK. There are numerous issues when using login/logout. It’s very hard to reproduce these issues, for eg. the last issue I reported took me 2 months to figure out how to reproduce the issue on a minimal example. It would be very benefitial for us if you could do a close examination of login/logout and everything that is connected to it and fix those issues.
We have been using Backendless for more than 4 months now and our app still can’t logout/login properly. Sometime it works fine and sometimes the whole app breaks after user does login after logout because of some issue with Backendless. Our temporary fix for this situation is that when the user wants to logout we quit the app after logout. Then login works properly after fresh startup of the app. It would be great for us if you could examine the login/logout workflow and make sure that Backendless works the same after them.
After logout and then login, there are few seconds after Beckendless connects.
It’s strangely big delay. The delay between disconnect and reconnect events for us is few hundred of milliseconds.
If you add/remove message listners in a period when Backendless still isn’t connected they won’t work.
We cannot reproduce this case. If we add listeners before socket is reconnected, they works correctly. Would be great if you create minimal reproducible example with this issue and share it.
There are numerous issues when using login/logout.
RT connection uses user token that is why login\logout events and rt listeners are linked. And we are glad you’ve discovered this issue and helped us to resolve it.
Our temporary fix for this situation is that when the user wants to logout we quit the app after logout.
I agree, this is very rough workaround. If you are not sure about RT stability you can just remove and then re-add all necessary listeners after logout by yourself. There is no need to restart whole app.
It’s strangely big delay. The delay between disconnect and reconnect events for us is few hundred of milliseconds.
Well for us it is a second or more. Our requests for Backendless API Services on CloudCode take 2-3 seconds sometimes. It could be because we are in Europe and Backendless servers are in US.
We cannot reproduce this case. If we add listeners before socket is reconnected, they works correctly. Would be great if you create minimal reproducible example with this issue and share it.
I agree, this is very rough workaround. If you are not sure about RT stability you can just remove and then re-add all necessary listeners after logout by yourself. There is no need to restart whole app.
We tried everything: adding/removing listeners, joining/leaving channels, tried adding/removing/joining/leaving at every possible time point of Backendless lifecycle. But it still wouldn’t work sometimes. It only works when the user is already logged in on app startup or when user logs in after the fresh app startup.
If you would like, we can always change the hosting zone. The process takes about 3-4 hours. Application ID and API keys won’t change, however the api endpoint will change from api.backendless.com to eu-api.backendless.com. Also, this will coast additional fee to cover engineer’s time.
Sorry for the delay and thank you for your patience. Unfortunately the RT logic sometimes can be a little confusing and it may cause some issues.
A new version 6.3.1 is released. Could you please check? For me it works fine now and listners added while Backendless isn’t connected should work fine.