Sending a message fails if interrupted by lifecycle management

[Michael Zanetti]

When being on a mobile data connection, sending messages frequently fails. For example if sending is slow, and the screensaver kicks in or I switch to another app. The message will be sitting there with the clock icon and never being sent. I have to manually resend the message and delete the original one. This also happens if the data connection is too weak and sending gets interrupted without app lifecycling kicking in.

[Cieniek (cieniek)]

Experienced same problem when trying to send a photo on slow connection. If a message is not fully send in 5 minutes it got stuck with the clock icon. The message got cancelled regardless if it was progressing or not.

If you try to observe the GUI all the time it would close itself around the time of the failure.

Additionally if you remove unfinished message (photo), the following one (created using the refresh button) would lose the preview / miniature.

[Dan González (gonrodda)]

Same here.

As noted in https://bugs.launchpad.net/libqtelegram/+bug/1473519/comments/2 this behaviour seems to be expected in current version. But it keeps bugging me since at workplace the mobile signal is far from decent.

Also I've experienced that these "clocked" messages can be removed or forwarded from swipe interaction but not when selected by holding and accessing action menu from the screen top right. (I don't know if I must report it as another another bug but I find it related to this one).

[Michael Zanetti (mzanetti)]

This has nothing to do with the duration... It fails if the message is not sent before either the screensaver kicks in or the user switches to another app.

[Michael Zanetti (mzanetti)]

This makes sending images on 2G connection close to impossible btw.

[Cieniek (cieniek)]

I don't think you are right Michael here. I tried to keep the app active by touching the screen and the result was same. I was using a slow Wi-Fi BTW.

[Michał Karnicki (karni)]

Here's a comment from a Telegram user:

"Having to keep Telegram open until the 3G network here in Berlin has sent a picture is the most pathetic experience I've ever had on a phone. A normal user will never accept this."

You can't dispute that. It's a terrible experience, yet I can't tell if we are doing anything on the platform level towards solving this real problem.

[Pat McGowan (pat-mcgowan)]

When we move to a telepathy plugin based solution I expect this would behave properly

[Michael Zanetti (mzanetti)]

@Pat, given that currently we are working on a not yet released version of a telegram app that does *not* integrate with telepathy, it seems moving to a telepathy plugin is at least another year away, very likely more. Can't we really think of some hotfix/workaround to get this problem solved in the meantime? Currently, completely disabling lifecycling for telegram using unsupported hacks is the only way to be able to use it on the go without starting to hate the phone.

[Pat McGowan (pat-mcgowan)]

We could whitelist telegram in the short term

[Michał Karnicki (karni)]

If we were to take that avenue, I would strongly recommend verifying the impact on battery. While I would love a concept of background service of some sort (and have time to work on it), I have not dedicated as much attention as I would like to to battery conservation. If the app was to run in the background all time, we would have to really make sure this doesn't worsen overall (battery) experience for the users.

[Thomas Voß (thomas-voss)]

From my perspective, the actual solution to this problem would be for telegram to hand over the upload to Ubuntu Download Manager (which should gain the ability to carry out such requests). In addition, failed uploads should be handled gracefully by the telegram app itself, so checking the state of outstanding uploads whenever it is started or resurrected.

[Michał Karnicki (karni)]

>From my perspective, the actual solution to this problem would be for
telegram to hand over the upload to Ubuntu Download Manager (which
should gain the ability to carry out such requests).

I agree, Thomas. Does anyone know if this is for the roadmap for the 'DownloadManager'? (the name can be confusing in context of uploads)

> In addition, failed uploads should be handled gracefully by the telegram app
itself, so checking the state of outstanding uploads whenever it is started
or resurrected.

Yes, that is correct. It is something we definitely want to improve when time allows.

[Sturm Flut (sturmflut)]

> From my perspective, the actual solution to this problem would be for telegram to hand over the upload to Ubuntu Download Manager (which should gain the ability to carry out such requests).

Doesn't that design mean the Ubuntu Download Manager has to know how to up- and download using any random protocol used on the internet? How would that be implemented in practice?

[Marco (jermy-07)]

Affecting me as well for images and messages. On another note: Is there any way to resend an image which failed to transmit? (Assuming the image is taken on-the-fly with the camera app opened from the telegram app)

[Michael Zanetti (mzanetti)]

FWIW, I'm running telegram now for months with a lifecycle exception. It works around this issue well and doesn't cause battery drain.

Maybe we need to rethink the timeout until suspending an app? I noticed that Android does that after a full minute. While that seems unneccessarily long to me, the 3 seconds we have now are really the source of those problems. We can't expect apps with network connectivity to be able to deal with all remote things in 3 seconds IMO.

Moving every upload to the download manager is probably the desirable long term solution but is again something that won't be happening realistically within any foreseeable future.

[Michał Karnicki (karni)]

FWIW you have my vote on that, +1