No information if server unavailable/offline (#37)
Daniel Wisnewski opened 8 years ago

If a server is offline or unavailable (or somebody mis-typed it in new account) iOS application will basically do nothing. Suggest a server timeout on login (and server unavailable error).

Also, perhaps unrelated, application does not do any activity during server shutdown (although I suppose this is due to the passive presence nature of the application?).

Andrzej Wójcik (Tigase) commented 8 years ago

Application should not inform user if it is not able to connect to XMPP server every time. If it should inform user then only after account is added for a first time.

Mobile devices are not always connected to networks which have a connectivity to internet, so it is possible that server is properly working and we should try to connect it at later time.

State of account connectivity is also displayed in More tab in accounts section, so you can verify it's state.

Also if we would notify user that we cannot connect to server when he is in place with poor network connectivity it would be very annoying for a user to get notifications ever few minutes or seconds. To overcome this we would need to disable account if we cannot connect to server, but this would require action from a user to reenable this account.

Due to above I do not thing this is a good idea as there is no way to tell if server is unavailable or offline? Both cases should be threatened differently and as iOS closes connection to server very fast after we leave client then there is almost no information at this time whether server is active or not. Moreover Push notification on which we are working will reduce usage of XMPP connection while application is in a background.

%kobit What do you think?

Artur Hefczyc commented 8 years ago

I think you both are right on this.

  1. I think the current client behavior is good for the public beta tests and even maybe for version 1.0

  2. We do not want the client to bother users every time there is a connection issue, it should attempt to silently reconnect

  3. However, it actually depends on the error. For some errors the client should actually to get back to a user with information. I think, over a time we should build more intelligence into the error detection in the client to give some feedback to a user when it makes sense. For example, if there is an incorrect password error, the client should always get back to a user for a correct input. I guess there might be some other circumstances when an action from a user makes sense. Simple connection lost, is a normal thing for a mobile device.

  4. I think also, some more visual feedback to a user on the current connection(s) status on "Recent" and "Contacts" would be very helpful. Or maybe some icon in the status line, which would change a color depending on the connection status. So, the user has an instant information on the connectivity without a need to get to "More" and check accounts.

  5. Also, if there is/was connectivity issue with some account, the client could store last error information per account and make it accessible to a user on demand.

But, as I said, these all can be slowly added for future versions.

Andrzej Wójcik (Tigase) commented 8 years ago

%kobit Few comments:

Artur Hefczyc wrote:

I think you both are right on this.

I think the current client behavior is good for the public beta tests and even maybe for version 1.0

We do not want the client to bother users every time there is a connection issue, it should attempt to silently reconnect

Yes, this is what it currently does.

However, it actually depends on the error. For some errors the client should actually to get back to a user with information. I think, over a time we should build more intelligence into the error detection in the client to give some feedback to a user when it makes sense. For example, if there is an incorrect password error, the client should always get back to a user for a correct input. I guess there might be some other circumstances when an action from a user makes sense. Simple connection lost, is a normal thing for a mobile device.

Support for wrong password, certificate issues or other important errors reported by server is already implemented.

I think also, some more visual feedback to a user on the current connection(s) status on "Recent" and "Contacts" would be very helpful. Or maybe some icon in the status line, which would change a color depending on the connection status. So, the user has an instant information on the connectivity without a need to get to "More" and check accounts.

Connection of which account should be displayed? There is very little space there and in case of:

  • roster - you see if contacts are online

  • chats list - you see contacts status

  • chat - contact status is presented on top of a chat (view header)

Also, if there is/was connectivity issue with some account, the client could store last error information per account and make it accessible to a user on demand.

Currently you will get alert about this, so user will need to take some action (if error is severe and we cannot continue without user intervention). In other cases it should just work.

But, as I said, these all can be slowly added for future versions.

Artur Hefczyc commented 8 years ago

depending on the connection status. So, the user has an instant information on the connectivity without a need to get to "More" and check accounts.

Connection of which account should be displayed? There is very little space there and in case of:

  • roster - you see if contacts are online
  • chats list - you see contacts status
  • chat - contact status is presented on top of a chat (view header)

Yes, this is true. However, if you have multiple accounts you cannot quickly know that one of them is offline. So what I meant is a small icon/indicator like a bulb or some kind of network icon which would have 3 states:

  1. Green - all accounts online

  2. Yellow - some accounts online and some offline

  3. Red - all accounts offline

Maybe we do not even need a separate icon. Maybe "Contacts" or "More" icon could change the color as described above.

Also, if there is/was connectivity issue with some account, the client could store last error information per account and make it accessible to a user on demand.

Currently you will get alert about this, so user will need to take some action (if error is severe and we cannot continue without user intervention). In other cases it should just work.

Yes, this is true as well. However, sometimes you cannot act right away when you receive the alert, and this may happen for many reasons. And then after a while you cannot remember what was wrong. So, a way to access last known error on the connection would be a nice feature.

In any case, I am changing this to future versions and the current behavior is good for the public beta.

Daniel Wisnewski commented 8 years ago

I can confirm most recent version has notifications supported for wrong/bad password, although if a server is offline (but has a valid SRV record) the application will not send message to user and act like device is online/logged in. The messenger does support a small icon for one status indication, but multiple accounts do not show the tiger icon w/status light.

Andrzej, should we create separate ticket for these issues?

Andrzej Wójcik (Tigase) commented 8 years ago

although if a server is offline (but has a valid SRV record) the application will not send message to user and act like device is online/logged in

No application will behave as account is disconnected (or at least it should). Please let me know (best using separate tasks linked to this one, in which application allows to send message without a warning or alert.

multiple accounts do not show the tiger icon w/status light

I have it for each of my accounts, however I have avatars set so instead of tiger icon I have my avatar. Please create task for this as well. I will look into this, as this maybe caused by usage of tigase instead of avatar (other type of processing is done in background).

Daniel Wisnewski commented 8 years ago

New tickets have been created for mentioned issues, I am closing this issue as the initial conditions have been resolved.

issue 1 of 1
Type
Bug
Priority
Normal
Assignee
RedmineID
5300
Version
Version 1.0
Issue Votes (0)
Watchers (0)
Reference
tigase/_clients/siskin-im#37
Please wait...
Page is in error, reload to recover