Incorrect account connection status

[afriedmanGlacier]

There are several scenarios where the Buddy status (and therefore isThreadOnline) are not correct.

For example:

1. 2 users have an active chat. 2nd User closes the app without logging out. 1st user still shows 2nd as active/online (green), and it takes about 10 minutes to change to inactive/offline.
2. 1st User allows app to go into background for several (3?) minutes. Then 1st user brings app back up. 2nd user now shows as offline even though 2nd user is active/online. Users can send messages to each other, but 1st user still shows 2nd user as inactive/offline and status never gets reset unless user manually logs out and logs back in.

Notes:
There is some code in OTRAppDelegate where it appears that someone started to address this but maybe ran into problems and never completed it. Both applicationWillTerminate and applicationDidBecomeActive have the following commented out line:
//FIXME? [OTRManagedAccount resetAccountsConnectionStatus];

Currently it seems that status can only be set to Active when a "presence" is received from the server, which appears to only happen when a user or a Buddy logs in.

[chrisballinger]

We might want to move away from visible presence because it means less in a mobile world. You're correct that the availability is error-prone, but ideally you should be able to send a message and use knock/xmpp push to nudge your contact into the available state.

There are some workarounds to fix the presence issue, but all are sort of hacky. Like you could show them as available if you receive a message from them or receive a delivery receipt, but that breaks the XMPP spec.

[afriedmanGlacier]

@chrisballinger I am wondering if it is possible to query the XMPP server (on applicationDidBecomeActive) and request connection status, which I don't think would be hacky. I don't know the XMPP spec well, but in searching this morning, it appears status can be requested via a presence stanza of type 'probe'?

I understand the thought about moving away from visible presence, but while its still in there, it should probably be as correct as possible. (If I have time, I will attempt a fix for this, but I'm still not super familiar with the code as a whole.)