The MMS lost story

lduboeuf

@jezek So on my side, did some tweaks for the UI part.
Now message when cellular-data is off is displayed like that:

For other cases, no changes

I wonder if we can simplify on telephony service for the notification part the message to "New MMS message received" instead of the "Oops...." and let user discover any errors within the messaging app. It will be easier to manage has we will not have to parse the msg, and check for different cases there.

One thing more, but will need to add some logic, in history service, can we take the received date (timestamp) from the previous message before deletion so that the MMS will not appear at the bottom of the list but as a replacement of the error message ?

domubpkm

Hello.
Just a little sidebar: can you tell me if MMS currently works for Android 9 devices in RC 8 or dev ?
Specifically for me, MMS don't work in RC 8 for Volla (cellular data ok, internet ok, sms ok, APN mms configured).

lduboeuf

@domubpkm idk, isn't that related ?: https://github.com/ubports/ubuntu-touch/issues/1657

Please move that question to support or issues on ubuntu touch or Volla directly ?

domubpkm

@lduboeuf ok. Maybe.
I signaled and asked.
Thank you

jezek

@lduboeuf said in The MMS lost story:

So on my side, did some tweaks for the UI part...

Thanks, will test.

I wonder if we can simplify on telephony service for the notification part the message to "New MMS message received" instead of the "Oops...." and let user discover any errors within the messaging app. It will be easier to manage has we will not have to parse the msg, and check for different cases there.

That's a nice idea, I'm not against. I will change the text.

One thing more, but will need to add some logic, in history service, can we take the received date (timestamp) from the previous message before deletion so that the MMS will not appear at the bottom of the list but as a replacement of the error message ?

Nice idea too, will implement.

jezek

Failed MMS redownload progress report:

This week these PR's got updated:

nuntium - send Received (uint - unix time) message parameter to telepathy-ofono, to ensure right place in message history. And Error (bool) and ErrorMessage (string) parameter got merged into one Error (string).
telepathy-ofono - on added message signal, fill message-received header with Received parameter (if found). Check and fill error message text from Error parameter.
history-service - no changes needed.
messaging-app - no changes, just rebased to xenial which changed upstream.
telephony-service - Just the MMS error text got truncated. Note: The PR wont build only for arm64 due to test fail. Seems not my fault, but needs to be fixed.

That's all this week. This projects is nearing it's end. If nothing goes wrong I'd say 2 weeks (without . documentation, tests and changelogs changes) and we are ready to test on dev, not only through ubports-qa.

Have a nice day.

jezek

Failed MMS redownload progress report:

This week I got rid of some TODOs in nuntium PR only.

@lduboeuf Can I ask you one more thing? Could you check (in messaging-app) if an error message is expired and if yes, don't allow to redownolad (hide the button and maybe change text). I'ts because I plan to delete and not listen to expired undownloaded messages in nuntium. And if the message is not listening in nuntium, then after clicking redownload in messaging-app, the message would be pending forever (until user deletes it). Thank you.

lduboeuf

@jezek Thanks for your weekly review of progress. I'm waiting it impatiently every Sunday evening

Good point for the expiry date, it needs to be done, will do it ASAP

lduboeuf

@jezek for the AutoRetrieve option, do you have already an idea what to do ?, or i can prepare if you want a setting callable from Dbus like for the MmmsEnabled here: https://github.com/ubports/nuntium/blob/0040206b63bd0a126e5242efa789a8201b7c5be0/cmd/nuntium/mediator.go#L447
I will need write access to Telephony-service PR though

let say "MmsAutoRetrieveEnabled" property name ?

Does the MMS notification message will have the same signature than a "cellular-off" one ?

jezek

@lduboeuf said in The MMS lost story:

@jezek for the AutoRetrieve option, do you have already an idea what to do ?, or i can prepare if you want a setting callable from Dbus like for the MmmsEnabled here: https://github.com/ubports/nuntium/blob/0040206b63bd0a126e5242efa789a8201b7c5be0/cmd/nuntium/mediator.go#L447
I will need write access to Telephony-service PR though

let say "MmsAutoRetrieveEnabled" property name ?

Does the MMS notification message will have the same signature than a "cellular-off" one ?

I haven't thought about it in such details yet. First, I would like to finish the failed mms issue. There are still some things to do. The MMS autoretrieval will be a separate project. So if you want to start ahead with the "MmsAutoRetrieveEnabled" setting (a good idea, the setting will be needed), just start a new draft (but I think it has time).

On another note. I thought to myself the other day, that it would be nice, if the messaging-app would show number of unread messages in icon, like teleports does.

lduboeuf

@jezek said in The MMS lost story:

@lduboeuf said in The MMS lost story:

@jezek for the AutoRetrieve option, do you have already an idea what to do ?, or i can prepare if you want a setting callable from Dbus like for the MmmsEnabled here: https://github.com/ubports/nuntium/blob/0040206b63bd0a126e5242efa789a8201b7c5be0/cmd/nuntium/mediator.go#L447
I will need write access to Telephony-service PR though

let say "MmsAutoRetrieveEnabled" property name ?

Does the MMS notification message will have the same signature than a "cellular-off" one ?

I haven't thought about it in such details yet. First, I would like to finish the failed mms issue. There are still some things to do. The MMS autoretrieval will be a separate project. So if you want to start ahead with the "MmsAutoRetrieveEnabled" setting (a good idea, the setting will be needed), just start a new draft (but I think it has time).

Yes, ok. I was first thinking to add a global setting ( like the MmsEnabled ) but i think that this flag should not be a user global setting, but related to the SIM account. Like MmsEnabled should also btw.
The thing is i don't know yet where it be defined...

On another note. I thought to myself the other day, that it would be nice, if the messaging-app would show number of unread messages in icon, like teleports does.

Yes, please add a feature request in messaging-app

jezek

If anybody installed nuntium PR since this weekend, please upgrade. I made mistake and nutium fails to acknowledge a successfully received multimedia message. Fortunately this error results in no data loss, just the MMS center will try to deliver your message more times. I'm sorry if I caused any inconvenience.

Keneda

@jezek
Only the one that never do anything never mistakes ^^

jezek

@lduboeuf said in The MMS lost story:

Yes, please add a feature request in messaging-app

Done here, but I don't know, how to flag it as feature request.

jezek

Failed MMS redownload progress report:

This week nuntium and messaging-app pull request drafts got update. @lduboeuf added code to messaging-app to not be able to initiate redownload of expired messages. And I fixed a bug in nuntium, wich I previously introduced. I've also made more work on nuntium localy, got rid of some TODOs, but I haven't fully tested the added code yet, so I'm not confident to push into PR draft right now. Will continue to work on this, see ya next time.

jezek

Failed MMS redownload progress report:

No commits to the drafts this week. Some work was done on nuntium locally, but like last week, it's not fully tested yet.

Keneda

@jezek said in The MMS lost story:

Don't be sad, we're not, take the time you need ^^

lduboeuf

@jezek no commits doesn't mean no progress. thank you for your months of efforts.

i'm already super happy with the feature as it is now, of course staying with 4 ubports-qa install is quite hazardous with devel updates but i can wait

jezek

Failed MMS redownload progress report:

This week I've been working on making nuntium message error handling more robust. That means, no message should be lost or unnoticed and if something really unexpected happens during incoming message handling (service problem, phone reboots, ...) message will try to recover or at least notify user during nuntium initialization. But today I've been mostly fixing errors I introduced during making nuntium more robust and found during testing, so I decided to not push new commits, until I test again (nuntium lacks unit tests, so I have to test manually).

I will report again, if when something changes.

Note: Most of my TODOs remaining in nuntium are about testing. If next tests don't uncover any errors, then only documentation. changelogs and a few unit tests are needed to be done and we can end the PR draft era and begin a review process.

AppLee

@jezek
Very good news.
Thank you so much for all the effort and trouble. Great contribution